From jdunrue at gmail.com  Sat Apr  1 16:10:34 2006
From: jdunrue at gmail.com (Jack Unrue)
Date: Sat, 1 Apr 2006 09:10:34 -0700
Subject: [cells-devel] tiny patch for running Cells 3 on CLISP
Message-ID: <d3df77800604010810j175cbf44j9c9acf0fac276b36@mail.gmail.com>

Hello Kenny,

As of CLISP 2.38 (if not earlier, I haven't checked), the
#+clisp defun for slot-definition-name is no longer necessary.

With that commented out, motor-control.lisp runs fine.  Just
thought you'd like to know :-)

I'm starting to look at Cells 3 with my first experiment being
to write a simple game as a demo for my Graphic-Forms
project, using Cells as the data model of course.  I'll let you
know how it goes.

--
Jack Unrue


From kentilton at gmail.com  Sat Apr  1 21:43:17 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Sat, 1 Apr 2006 16:43:17 -0500
Subject: [cells-devel] tiny patch for running Cells 3 on CLISP
In-Reply-To: <d3df77800604010810j175cbf44j9c9acf0fac276b36@mail.gmail.com>
References: <d3df77800604010810j175cbf44j9c9acf0fac276b36@mail.gmail.com>
Message-ID: <a44bc6a10604011343i292faabcw6242190e52cc7a16@mail.gmail.com>

On 4/1/06, Jack Unrue <jdunrue at gmail.com> wrote:
>
> Hello Kenny,
>
> As of CLISP 2.38 (if not earlier, I haven't checked), the
> #+clisp defun for slot-definition-name is no longer necessary.


Aha! I spotted that when cleaning up the code and had a feeling it could go.
Thanks for the patch.

With that commented out, motor-control.lisp runs fine.  Just
> thought you'd like to know :-)
>
> I'm starting to look at Cells 3 with my first experiment being
> to write a simple game as a demo for my Graphic-Forms
> project, using Cells as the data model of course.  I'll let you
> know how it goes.


Please do, and I will be happy to help if you get stuck. I try to make up
with support what I have omitted by way of doc.

Did you look at the Celtk module which is alongside Cells in the Cells
project repository? That may give you some ideas on how to proceed. Note
that Tk required a lot more handholding than I have encountered with other
systems, so Celtk may have complexities your set-up will not -- I guess to
be fair it is to be expected that driving an OO framework from a second
Cells-based OO framework will be harder than driving a purely procedural...
well, if you are using MFC, maybe not.

Anyway, let me know if you would like a second opinion on anything.

ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060401/0c56d7d1/attachment.html>

From fgoenninger at prion.de  Sun Apr  2 01:20:43 2006
From: fgoenninger at prion.de (Goenninger, Frank)
Date: Sun, 2 Apr 2006 03:20:43 +0200
Subject: [cells-devel] Celtk: How to set title of Wish window and also name
	of app ?
Message-ID: <F43CECE8-7EFF-46B9-A4AA-106AA92E3265@prion.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Kenny and all others:

I do have the following mini app now:

- -x-x-x-x-x-

(defmodel psu-rc-app (window)
   ()
   (:default-initargs
       :id :psu-rc-app-w
       :title$ "System Power Supply Remote Control (Version A.01.00)"
       :kids (c? (the-kids
		  (app-menubar)))))

;; THIS IS HOW I SET THE TITLE OF THE WISH SHELL WINDOW
;; Any better way?

(defmethod initialize-instance :after ((self psu-rc-app) &key)
   (tk-format '(:configure "title") "wm title . HI"))


(defun app-menubar ()
   (mk-menubar
      :id :psu-rc-menu-bar
      :kids (c? (the-kids
		  (mk-menu-entry-cascade-ex (:label "File")
		     (mk-menu-entry-separator)
		     (mk-menu-entry-command
		        :label   "Quit"
		        :command "exit"))))))

(defun run-psu-rc-app ()
   (cells-reset 'tk-user-queue-handler)
   (tk-test-class 'psu-rc-app))

- -x-x-x-x-x-

Hmm - now I wonder if this is really the right way to set the title  
of the window ...

Next question: On the Mac there is the Application name displayed in  
the top left corner when an app gets activated. This always says  
"Wish" which is something I want to set to the my own application  
name .. Purely a Mac and Tcl/Tk problem but ...

Thanks for any feedback.

Cheers!

   Frank

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.5 (Build 5050)

iQIVAwUBRC8m8GAKVUddnkqnAQpQhA/9GkwObg42wTUXiS2faUVNEqP57/nS2OqF
++7HRu2s2NCGvanLRCoJZOMVXrsasHE0K7izLCuMJAqF67YDr6UsO8EOJVkPHWIg
ogb6nc5FYO/pAR2MzbuH00JUURs4VSNTc61bC+JV47kzlkt5Uzx1BMNOWZoNWrUs
lPWanXxDNcmlbPmSY6Jz252/kzR3jyGlbQViBqZtPNkkrCuip8Bs39VBqr4iaQRR
LVMisvjas/is3KbBIVlAyLpX2gBvEivPa+oXfTmnG0rWUbfkYKms7EUT9uwWhxVG
TOTP/8eZkFinPtObs/8hUcKNDSPs/4rAzPvH75ioOGZGkM2yAeNC6rTbOgyDvOvh
bEBGhO20e064CmowKfbqZNFBHwmCtVvMopFhSMeaFEwBMPqjutAyWQ0F8/CXd121
BeA6ARRwi80q/hXPy38n80udY6XPkgNlNp7WAKIIoyiqZuaC9TMgik0t+W6WKdnq
qrm1sZ4arT6tkzoBrobShZAk4pTl+k4ukB0wXIhwPPOUHR/mzPJzOKnkEFNtsAXi
b1oF9A6deu8dB25HOv+aNRF6yUUAwf8eUvBhCpIGkfyjP6/hw2h56bgyPkmriH8Y
58BeT8tEoxNQhmoDryWbIRFgIVGjRw1d4D5yo8I6xeXmPXitGymaIDs9AVu9srhp
shYQCEvr3NA=
=+dKG
-----END PGP SIGNATURE-----



From kentilton at gmail.com  Sun Apr  2 04:17:53 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Sat, 01 Apr 2006 23:17:53 -0500
Subject: [Fwd: Re: [cells-devel] Celtk: How to set title of Wish window and
	also name	of app ?]
Message-ID: <442F5071.6080501@gmail.com>



-------- Original Message --------
Subject: 	Re: [cells-devel] Celtk: How to set title of Wish window and 
also name of app ?
Date: 	Sat, 01 Apr 2006 23:12:23 -0500
From: 	Ken Tilton <kentilton at gmail.com>
Reply-To: 	kentilton at gmail.com
To: 	Goenninger, Frank <fgoenninger at prion.de>
References: 	<F43CECE8-7EFF-46B9-A4AA-106AA92E3265 at prion.de>



Goenninger, Frank wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>Hi Kenny and all others:
>
>I do have the following mini app now:
>
>- -x-x-x-x-x-
>
>(defmodel psu-rc-app (window)
>   ()
>   (:default-initargs
>       :id :psu-rc-app-w
>       :title$ "System Power Supply Remote Control (Version A.01.00)"
>       :kids (c? (the-kids
>		  (app-menubar)))))
>
>;; THIS IS HOW I SET THE TITLE OF THE WISH SHELL WINDOW
>;; Any better way?
>
>(defmethod initialize-instance :after ((self psu-rc-app) &key)
>   (tk-format '(:configure "title") "wm title . HI"))
>  
>
Yes and no. No in that, no, there is not a better way. :) Yes in that 
there should be. :)

Since there is only one Tk class like this, a fancy macro might not have 
much value. What we need is a bunch of:

(defobserver title$ ((self window))   
   (tk-format '(:configure "title") "wm title . ~a" (or new-value 
"Untitled")))

...observers, one per "wm XXXX...." that might follow from a window 
attribute. Note that, unlike intervening during i-i, this works even on 
/changes/ to the title (which would be unusual, but for other window 
attributes perfectly normal. so let's hand;e the general case.

Also... no, sorry, i forgot myself: the ii call to tk-format gets 
deferred until the tk-client-que-handler decides to dispatch configures, 
which is after things get made, so the window has been instantiated on 
the TK side before the tile change gets dispatched.

Anyway, if someone wants to code up the observers I will happily add 
them to Celtk, if not I will certainly get to them eventually as my need 
arises. Right now I am going quietly mad trying to make sense of Tcl/Tk 
handling of fonts and text items in a canvas. :)

As for the application name, er, can you copy wish.exe to frank.exe? 
Otherwise, if the doc does not help, I would try comp.lang.tcl. But if 
there is anyway to control that, I imagine we can get Celtk to handle it.

ken



-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060401/1a0a2e5d/attachment.vcf>

From kentilton at gmail.com  Sun Apr  2 13:19:46 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Sun, 2 Apr 2006 09:19:46 -0400
Subject: [Fwd: Re: [cells-devel] Celtk: How to set title of Wish window
	and also name of app ?]
In-Reply-To: <442F5071.6080501@gmail.com>
References: <442F5071.6080501@gmail.com>
Message-ID: <a44bc6a10604020619w6b4848ffg4916033216cbba4f@mail.gmail.com>

On 4/2/06, Ken Tilton <kentilton at gmail.com> wrote:
>
>
> Since there is only one Tk class like this, a fancy macro might not have
> much value. What we need is a bunch of:
>
> (defobserver title$ ((self window))
>    (tk-format '(:configure "title") "wm title . ~a" (or new-value
> "Untitled")))
>
> ...observers, one per "wm XXXX...." that might follow from a window
> attribute. Note that, unlike intervening during i-i, this works even on
> /changes/ to the title (which would be unusual, but for other window
> attributes perfectly normal. so let's hand;e the general case...


...

Anyway, if someone wants to code up the observers...


OK, got a good night's sleep, not feeling so lazy now. Look for me to fill
in this gap shortly. Trouble is I am already wreaking havoc on the
Canvas/Item component to suit my needs (fancier layout scheme that I expect
to use eventually for widgets as well) and it has already broken the demos
by not being compatible with the classic Tk scheme. I can /probably/ fix
that with a couple of carefully-placed if forms. we'll see.

ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060402/ee474a59/attachment.html>

From kentilton at gmail.com  Mon Apr  3 05:12:40 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Mon, 03 Apr 2006 01:12:40 -0400
Subject: [cells-devel] Celtk: How to set title of Wish window and also name
	of app ?
In-Reply-To: <60447E64-660E-4FC7-BF2E-3E455B354605@prion.de>
References: <F43CECE8-7EFF-46B9-A4AA-106AA92E3265@prion.de>
	<442F4F27.8000008@gmail.com>
	<60447E64-660E-4FC7-BF2E-3E455B354605@prion.de>
Message-ID: <4430AEC8.7050904@gmail.com>

Frank Goenninger wrote:

> Another question:
>
> Am 02.04.2006 um 06:12 schrieb Ken Tilton:
>
>> Goenninger, Frank wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA512
>>>
>>> Hi Kenny and all others:
>>>
>>> I do have the following mini app now:
>>>
>>> - -x-x-x-x-x-
>>>
>>> (defmodel psu-rc-app (window)
>>>   ()
>>>   (:default-initargs
>>>       :id :psu-rc-app-w
>>>       :title$ "System Power Supply Remote Control (Version A.01.00)"
>>>       :kids (c? (the-kids
>>>           (app-menubar)))))
>>
>
> Why does the title not get set via this default-initargs statement ?

This is the same story: I just have not done anything yet to handle the 
window class itself.

Background: If you expand any of the (deftk <widget>...) forms 
(actually, I strongly recommend you do that and stare at /all/ the 
varieties of code) you will see they expand into quite a bit of code, 
including a (defobserver <config parameter> ...) for every slot/tk 
config parameter. The way Celtk (and Cells-Gtk) work is that CLOS 
classes are defined for every TK widget type. A CLOS slot is defined for 
every tk config parameter. So with widgets you just set the 
corresponding CLOS instance slot and a defobserver sends that to Tk via: 
"<widget> configure -<config param name> <value from CLOS slot>".

I just need to do for the window class what I did with all the widgets 
and canvas items (the other job deftk handles). What title$ needs is:

  (defobserver title$ ((self window))
     (tk-format '(:configure "title") "wm title . ~s" (or new-value 
"Untitled")))

As I look at the other "wm..." commands I can see I first need to add 
some slots to the window class and then for each a defobserver to shoot 
the value across to Tk on any change.

[Side note: if you track down the mechanism by which make-instance leads 
to a corresponding TK widget creation, you will find some code that 
sweeps throug all the slots populated at make-instance time and includes 
thos config options in the widget creation. Which is why the generated 
defobservers check for old-value-boundp; the first time the observer 
gets invoked (the only time old-value-boundp is nil) is during 
make-instance, and the observer need not do anything since make-instance 
(eventually) gets the configs across in the widget creation command.

>
> And another one:
>
> I see there is the title$ slot of a window. How do I setf this  
> correctly ?
> The following does not work:
>
> (setf (title$ (fm^ :psi-rc-app-w)) "my new title")
>
> It (of course) emits an error that title$ is not a valid function -  
> yes, no, ahem, what? why?

I am not sure I have the same code you have, since I have already 
changed that slot's initform thus:

  (title$ :initarg :title$ :accessor title$  :initform (c? 
(string-capitalize (class-name (class-of self)))))

So your error could be for two reasons. Either I originally coded it thus

  (title$ :reader title$....)

thinking the title$ would never change, which is nonsense because a doc 
window starts out "Untitled" and then that changes when they save. 
Anyway, if I do not tell CLOS to create a writer it will not do so. 
Simple. But I doubt I specified just "reader". More likely (because even 
i can see it on the current code base) title$ is not exported and you 
are playing around in celtk-user, as I did deliberately to find out 
which symbols need to be exported.

So just add title$ to the symbols exported from the defpackage :celtk form.

>
> Thanks for some help here., 


The greater help I can offer is what I do when I cannot believe my eyes 
on an error: (apropos "title$"), though we both use AllegrroCL so we get 
to use the groovy Apropos dialog. That not only shows you if a symbol is 
exported, it will show you if there is a setf as well as a reader. In a 
case like yours where you have already compiled code and it has failed, 
you will see the symbol title$ in both the celtk and celtk-user 
packages. That is a tip-off that the celtk symbol was not exported, 
because had it been the compiler would not have interned a new symbol in 
celtk-user when it got to the reference to title$.

kt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060403/01a32bf3/attachment.vcf>

From jdunrue at gmail.com  Mon Apr  3 06:50:18 2006
From: jdunrue at gmail.com (Jack Unrue)
Date: Mon, 3 Apr 2006 00:50:18 -0600
Subject: [cells-devel] tiny patch for running Cells 3 on CLISP
In-Reply-To: <a44bc6a10604011343i292faabcw6242190e52cc7a16@mail.gmail.com>
References: <d3df77800604010810j175cbf44j9c9acf0fac276b36@mail.gmail.com>
	<a44bc6a10604011343i292faabcw6242190e52cc7a16@mail.gmail.com>
Message-ID: <d3df77800604022350v5c00e54aic8dbaa3fb2f03c33@mail.gmail.com>

On 4/1/06, Ken Tilton <kentilton at gmail.com> wrote:
>
> Please do, and I will be happy to help if you get stuck. I try to make up
> with support what I have omitted by way of doc.
>
> Did you look at the Celtk module which is alongside Cells in the Cells
> project repository? That may give you some ideas on how to proceed. Note
> that Tk required a lot more handholding than I have encountered with other
> systems, so Celtk may have complexities your set-up will not -- I guess to
> be fair it is to be expected that driving an OO framework from a second
> Cells-based OO framework will be harder than driving a purely procedural...
> well, if you are using MFC, maybe not.
>
> Anyway, let me know if you would like a second opinion on anything.

Just wanted to follow up...I'm in the midst of cleaning up some
GDI handle leaks in my code, so I haven't gotten back to Cells
just yet. Hopefully soon.

--
Jack Unrue


From kentilton at gmail.com  Mon Apr  3 10:36:00 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Mon, 03 Apr 2006 06:36:00 -0400
Subject: [cells-devel] Celtk: How to set title of Wish window and also name
	of app ?
In-Reply-To: <4430AEC8.7050904@gmail.com>
References: <F43CECE8-7EFF-46B9-A4AA-106AA92E3265@prion.de>
	<442F4F27.8000008@gmail.com>
	<60447E64-660E-4FC7-BF2E-3E455B354605@prion.de>
	<4430AEC8.7050904@gmail.com>
Message-ID: <4430FA90.1090503@gmail.com>

Ken Tilton wrote:

> Frank Goenninger wrote:
>
>> Another question:
>>
>> Am 02.04.2006 um 06:12 schrieb Ken Tilton:
>>
>>> Goenninger, Frank wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA512
>>>>
>>>> Hi Kenny and all others:
>>>>
>>>> I do have the following mini app now:
>>>>
>>>> - -x-x-x-x-x-
>>>>
>>>> (defmodel psu-rc-app (window)
>>>>   ()
>>>>   (:default-initargs
>>>>       :id :psu-rc-app-w
>>>>       :title$ "System Power Supply Remote Control (Version A.01.00)"
>>>>       :kids (c? (the-kids
>>>>           (app-menubar)))))
>>>
>>>
>>
>> Why does the title not get set via this default-initargs statement ?
>
>
> This is the same story: I just have not done anything yet to handle 
> the window class itself.

It just occurred to me that you might well be wondering "So why the 
$%^#@& is the title$ slot there?!". To be honest, I was wondering 
myself. :) Then I noticed some code left over from when I did Celtic and 
was not even using WITH-LTK from the LTK package (which is the LTK way 
of initiating wish):

(defmodel window (composite-widget)
  ((wish :initarg :wish :accessor wish
     :initform (wish-stream *wish*)
     #+(or) (c? (do-execute "wish84 -name testwindow"
                     nil #+not (list (format nil "-name ~s" (title$ 
self))))))

So I kinda misdirected you by leaving that old title$ slot behind when I 
did Celtk, which was meant to be more the LTk extension where Celtic was 
a (radical) LTk fork. Aside: the Celtk defpackage import from Ltk 
reveals that, in the end, only the LTk core got used by Celtk, but that 
is worth something.

Anyway, now I see how I confused things for you by leaving behind that 
vestigial code. Sorry for wating your time.

kt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060403/69ba3cf4/attachment.vcf>

From kentilton at gmail.com  Mon Apr  3 20:10:54 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Mon, 03 Apr 2006 16:10:54 -0400
Subject: [cells-devel] Re: Cells: How to later set a formula for a cell ?
In-Reply-To: <B2262766-74E0-4D82-9D2B-0FA7B7905D8D@prion.de>
References: <B2262766-74E0-4D82-9D2B-0FA7B7905D8D@prion.de>
Message-ID: <4431814E.7060905@gmail.com>

Goenninger, Frank wrote:

> Hi Kenny,
>
> currently heavily playing wit Celtk...
>
> I have up to now only set a cell's formula by using directly (c? ...)  
> with default-initargs. Now I am stopped cold by the fact that I have  
> to be able to set the formula by some setf form. How to do that in a  
> conforming way ? 


Download KR from the Garnet system, they have a million backdoors like 
that. :)

What's the big picture on this? Maybe there is a way to do it without an 
alley-oop.

If you sell me on the need, and you can at least start the slot as 
c-input, I imagine there is some way to do this.

If you do not sell me on the need, I will still give you some pointers* 
on how to mess up the beauty of Cells yourself.:) But I think you will 
still need to start with a c-input, or you will lose the dependencies 
(Cells does not record dependencies on slots not mediated by Cells.)

ken (going out for groceries soon)

* Look at c-install, md-awaken, c-awaken-cell, and their neighbors.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060403/df047ee5/attachment.vcf>

From fgoenninger at prion.de  Mon Apr  3 20:36:49 2006
From: fgoenninger at prion.de (Frank Goenninger)
Date: Mon, 3 Apr 2006 22:36:49 +0200
Subject: [cells-devel] Re: Cells: How to later set a formula for a cell ?
In-Reply-To: <4431814E.7060905@gmail.com>
References: <B2262766-74E0-4D82-9D2B-0FA7B7905D8D@prion.de>
	<4431814E.7060905@gmail.com>
Message-ID: <76259C5F-AE44-4ABE-8E47-6C03F95362C2@prion.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am 03.04.2006 um 22:10 schrieb Ken Tilton:

> Goenninger, Frank wrote:
>
>> Hi Kenny,
>>
>> currently heavily playing wit Celtk...
>>
>> I have up to now only set a cell's formula by using directly  
>> (c? ...)  with default-initargs. Now I am stopped cold by the fact  
>> that I have  to be able to set the formula by some setf form. How  
>> to do that in a  conforming way ?
>
>
> Download KR from the Garnet system, they have a million backdoors  
> like that. :)

Don't get me tempted... You risk loosing a real Cells adict ;-)

>
> What's the big picture on this? Maybe there is a way to do it  
> without an alley-oop.

I certainly hope there is!

The big picture - and I begin wondering if phrased my original  
question as misleading  - is that I have laaarge code fragments being  
complex rules for a cell formula. I want to stick that in a separate  
function in order to code in a more readable way ?! When trying to  
achieve this I figured that c? does not much but I simply found that  
I need the context of the cell slot to stick some rule to it.

Second use case:

Imagine I have a knowledge base (using inference) that produces cell  
formulae based on facts and rules I have put into the knowledge base.  
So, I have to be able to act on lists of structure ( cell-id formula- 
form ) and stick those new formula-forms into the given cells with id  
cell-id.

> If you sell me on the need, and you can at least start the slot as  
> c-input, I imagine there is some way to do this.

Is the above enough ?

>
> If you do not sell me on the need, I will still give you some  
> pointers* on how to mess up the beauty of Cells yourself.:) But I  
> think you will still need to start with a c-input, or you will lose  
> the dependencies (Cells does not record dependencies on slots not  
> mediated by Cells.)
>
> ken (going out for groceries soon)
>
> * Look at c-install, md-awaken, c-awaken-cell, and their neighbors.

Looking, even staring at them ?!

Cheers
    Frank



-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.5 (Build 5050)

iQIVAwUBRDGHZmAKVUddnkqnAQo7/w/9HuR0L0u/k6eycdzvosaQ+FGIIky8GTFn
Hm9rg/dHctEPV6b4/7JWvIolyQd+g2AzRwjEYZyN5ZC3kq9sASTQWYsFL3aoCEZS
pvlcqEeikSu6Rh5GRz3mxl0HpgcJuCqYcYLA5H5vUxaOVNR2XSCpezxjQPA0WxWa
/WZbKlmoCLCXhc/DP5ZNVju9zkWD0MH3HyUrFpknninKNJuURN+fWQ+CHwJu1lTd
uJRstVlH9gcNpLvEFx8tFSIrVN0i3d9CO0+UKb+J4+HexUoM7HyMbZn/ZPY/2X0D
ABbiuNu+hmYVgCwh/lL0KWIwO5ocdFRQM8EfiDCe5Shsq6NkQYaj1Qy03hR1hx5h
Xy87/BmeElTgBN5iRQKIxAJG+8Y+h0fci2Csg9IKYpwlpGFTU6iyGH3fWq6wTMrv
xTYFtYQNa+d2A0B6rCvwdUJIYVw3JeVkNd8ldCNGRye5z23XhuvyhxlqbJ3iLnva
RTFvrg3X4oUZlEIB4ZXNzsT9jzVu9dRRE7UdPcCvxjHGaIJrQ+SoauYg4CPtDa8Z
0zJCjhbsx6c5tNlhzUaaDub3qE5Xg65TZ1nKQJOk9qGklBmg9jt+skDUfFm5Ask6
TZQi8LgnFQQlCTU5I1heISohp83OmkBUYXR4hDPpjT1dc/O2UuJFEs0Eq1JYnqJo
pzUwdGIAp54=
=AKYa
-----END PGP SIGNATURE-----



From kentilton at gmail.com  Mon Apr  3 21:27:53 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Mon, 03 Apr 2006 17:27:53 -0400
Subject: [cells-devel] Re: Cells: How to later set a formula for a cell ?
In-Reply-To: <76259C5F-AE44-4ABE-8E47-6C03F95362C2@prion.de>
References: <B2262766-74E0-4D82-9D2B-0FA7B7905D8D@prion.de>
	<4431814E.7060905@gmail.com>
	<76259C5F-AE44-4ABE-8E47-6C03F95362C2@prion.de>
Message-ID: <44319359.9090002@gmail.com>

Frank Goenninger wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>Am 03.04.2006 um 22:10 schrieb Ken Tilton:
>
>  
>
>>Goenninger, Frank wrote:
>>
>>    
>>
>>>Hi Kenny,
>>>
>>>currently heavily playing wit Celtk...
>>>
>>>I have up to now only set a cell's formula by using directly  
>>>(c? ...)  with default-initargs. Now I am stopped cold by the fact  
>>>that I have  to be able to set the formula by some setf form. How  
>>>to do that in a  conforming way ?
>>>      
>>>
>>Download KR from the Garnet system, they have a million backdoors  
>>like that. :)
>>    
>>
>
>Don't get me tempted... You risk loosing a real Cells adict ;-)
>
>  
>
>>What's the big picture on this? Maybe there is a way to do it  
>>without an alley-oop.
>>    
>>
>
>I certainly hope there is!
>
>The big picture - and I begin wondering if phrased my original  
>question as misleading  - is that I have laaarge code fragments being  
>complex rules for a cell formula. I want to stick that in a separate  
>function in order to code in a more readable way ?!
>
First of all, a trick I use all the time because I never like to look at 
too much code at once:

(make-instance 'thing :myslot (big-long-thing-myslot-rule-1)) ;; observe 
that there is no c? here

(defun big-long-thing-myslot-rule-1 ()
   (c? <big long rule>)) ;; here is the c?

Second of all, do not forget that Cells work by dynamic not lexical 
reference, so:

> When trying to  
>achieve this I figured that c? does not much but I simply found that  
>I need the context of the cell slot to stick some rule to it.
>  
>
I doubt it. :) Are you talking about the (^myslot) forms not working? 
That just captures the lexical variable self. I use ^macros all the 
time, because I pretend I am doing Smalltalk and always call the chief 
instance to a function "self". So I get to use ^macros all over the 
place, in a rule or not.

If you are talking about .cache, and do not want to pass it down the 
call tree, we will have to start exposing Cell internals.

oh, I forgot to say: just do what you always do when a function gets too 
big. Split it up. Again, any /dynamic/ reference will establish a 
dependency, ie, the reference does not need to appear in the code of the 
rule (that would be lexical). So divide big-long-rule up into a driver 
and a bunch of helper functions as you would do normally and it will all 
Just Work.

>Second use case:
>
>Imagine I have a knowledge base (using inference) that produces cell  
>formulae based on facts and rules I have put into the knowledge base.  
>So, I have to be able to act on lists of structure ( cell-id formula- 
>form ) and stick those new formula-forms into the given cells with id  
>cell-id.
>  
>
I have thought about such a thing. I have not actually had to do it (so 
maybe reality would change my approach) but I would simply keep the two 
beasts apart, Cells and KB:

   (make-instance 'thing :rule-driven-slot (c? kb-apply 
(kb-compute-formula <fact-1> <fact-s> <circumstance-3>))

Observe that as the parameters to kb-compute-formula change you will get 
a new rule as well as new computation. The downside is that, as the 
slots accessed only during kb-apply change, you will unnecessarily 
recompute the rule to be kb-applied. So:

  ...:rule-to-kb-apply (c? (kb-compute-formula f1 f2 c3))
     :rule-driven-slot (c? (kb-apply (^rule-to-kb-apply))

ie, Let Cells do its primitive little dataflow thing and let the fancy 
KR/KB system do its clever machine thinking and do not bother them with 
each other's burden.

ken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060403/503aba7a/attachment.vcf>

From kentilton at gmail.com  Wed Apr  5 12:34:05 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Wed, 5 Apr 2006 08:34:05 -0400
Subject: [cells-devel] Re: Celtk/Cells3 declarative,
	dataflow paradigm contrasted with Ltk/imperative paradigm
In-Reply-To: <87hd58zkhp.fsf@mobile.landahl.org>
References: <WRBUf.23$aX7.20@fe11.lga> <87ek0c3ctg.fsf@mobile.landahl.org>
	<a44bc6a10604042138u3336437cl143fd173b4e44c16@mail.gmail.com>
	<87hd58zkhp.fsf@mobile.landahl.org>
Message-ID: <a44bc6a10604050534o7e793adfn6ed4cc6982d8d9a2@mail.gmail.com>

John,

Sorry, it was late, I reacted too hastily. That error message looks wild,
not sure what to make of it.

Unfortunately, I have no Linux system. But the original developers of LTk
use Linux and are looking at Celtk these days. I have not heard from them,
but a query on the cells-devel mailing list might turn up someone using both
Linux and Celtk.

Otherwise, it might helpt to track down tk-format-now and tweak it so that
the branch to display messages sent to Tk always fires, then see (a) if
those messages look okay (post them to cells-devel) and (b) how far you get
before Celtk dies.

kt


On 4/5/06, John Landahl <john at landahl.org> wrote:
>
> > Right at the top of ltktest-cells-inside.lisp you will find:
> >
> > #+test-ltktest
> > (progn
> >   (cells-reset 'tk-user-queue-handler)
> >   ; ...huge comment elided....
> >   (tk-test-class 'ltktest-cells-inside))
>
> Yep, saw that, and I suppose I expected that loading celtk would set
> test-ltktest.  Removing the #+ and re-evaluating does startup the
> test.
>
> However, the result is a bunch of errors and a big traceback.  Here's
> what looks like the most useful chunk:
>
> 0> numparse | :=> 42read-data:UNKNOWNcolor name "systembuttonface"
>
> read-data:INVALIDcommand name ".cv-scroller.test-canvas"
>
>
> INVALIDCOMMANDNAME.cv-scroller.test-canvasUNKNOWNCOLORNAMEsystembuttonfaceBADWINDOWPATHNAME.cv-scroller.test-canvasINVALIDCOMMANDNAME.cv-scroller.test-canvas.bkg-popINVALIDCOMMANDNAME.cv-scroller.test-canvas.bkg-popINVALIDCOMMANDNAME.cv-scroller.test-canvas.bkg-popINVALIDCOMMANDNAME.cv-scroller.test-canvas.bkg-popCANREAD.cv-scroller.test-canvas.bkg-pop.bkg
> An error of type READER-ERROR has occured: READER-ERROR on
> #<TWO-WAY-STREAM
>                                                              :INPUT-STREAM
> #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}>
>
> :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>:
> illegal terminating character after a colon: #\
> 0: (SB-DEBUG:BACKTRACE
>     536870911
>     #<SB-SYS:FD-STREAM for "a constant string" {AFCDB01}>)
> 1: (LTK::TRIVIAL-DEBUGGER #<READER-ERROR {AA34AF1}> #<unavailable
> argument>)
> 2: (INVOKE-DEBUGGER #<READER-ERROR {AA34AF1}>)
> 3: (ERROR READER-ERROR)
> 4: (SB-IMPL::%READER-ERROR
>     #<TWO-WAY-STREAM
>       :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}>
>       :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>
>     "illegal terminating character after a colon: ~S")
> 5: (SB-IMPL::READ-TOKEN
>     #<TWO-WAY-STREAM
>       :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}>
>       :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>
>     #\:)
> 6: (READ-PRESERVING-WHITESPACE
>     #<TWO-WAY-STREAM
>       :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}>
>       :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>
>     NIL
>     NIL
>     T)
> 7: (READ-PRESERVING-WHITESPACE
>     #<TWO-WAY-STREAM
>       :INPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 14" {A755EC9}>
>       :OUTPUT-STREAM #<SB-SYS:FD-STREAM for "descriptor 13" {A755541}>>
>     NIL
>     NIL
>     NIL)
> 8: (LTK::MAIN-ITERATION :BLOCKING T)
> 9: ((LAMBDA ()))
> 10: ((LABELS LTK::USE-DEBUGGER)
>      #<FUNCTION LTK::TRIVIAL-DEBUGGER>
>      #<CLOSURE (LAMBDA #) {AA3477D}>)
> 11: (LTK:MAINLOOP :SERVE-EVENT NIL)
>
> I'm running SBCL 0.9.11 on Linux, if it matters.  My Tk version is
> 8.4.
>
> > No, but do compare it to 'ltktest-cells-inside to get a feel for how
> > Cells transforms development.
>
> I definitely will.  I'd very much like to do more declarative
> programming where it makes sense, and (as you and others have pointed
> out) UIs are a natural fit.  So it will be good to compare your
> approach to the more usual (less intelligent) approach.
> --
> John Landahl <john at landahl.org>
> http://landahl.org/john
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060405/72b777fa/attachment.html>

From kentilton at gmail.com  Wed Apr  5 14:38:59 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Wed, 5 Apr 2006 10:38:59 -0400
Subject: [cells-devel] Re: Celtk/Cells3 declarative,
	dataflow paradigm contrasted with Ltk/imperative paradigm
In-Reply-To: <a44bc6a10604050534o7e793adfn6ed4cc6982d8d9a2@mail.gmail.com>
References: <WRBUf.23$aX7.20@fe11.lga> <87ek0c3ctg.fsf@mobile.landahl.org>
	<a44bc6a10604042138u3336437cl143fd173b4e44c16@mail.gmail.com>
	<87hd58zkhp.fsf@mobile.landahl.org>
	<a44bc6a10604050534o7e793adfn6ed4cc6982d8d9a2@mail.gmail.com>
Message-ID: <a44bc6a10604050738p7690d84eu8557bc98b3d1482f@mail.gmail.com>

I just grabbed the CVS version of Cells and Celtk (I had already changed the
latter quite a bit) and tested OK. Here is the output I see to wish84/Tk:


tk> menu .mnu75 -tearoff 0 -type menubar
tk> menu .mnu75.mnu78 -tearoff 0
tk> menu .mnu75.mnu78.mnu92 -tearoff 0
tk> frame .cv-scroller -class frame
tk> canvas .cv-scroller.test-canvas -background systembuttonface
-scrollregion {0 0 500 400}
tk> senddata [.cv-scroller.test-canvas create text  10 10  -anchor "nw"
-text "Ltk Demonstration"]
tk> senddata [.cv-scroller.test-canvas create line  250.0 400.0 300.23407
108.66162 155.33328 366.35382 378.16644 172.06824 103.135544 280.50952
398.60135 270.4362 116.8235 180.97812 352.37134 359.63623 190.25645
112.41109 260.21606 399.6517 290.49127 105.5685 163.47768 372.5312 372.56125
163.52028 105.55452 290.44135 399.64813 260.26807 112.43175 190.2089
359.60065 352.40945 181.02466 116.79939 270.38467 398.60843 280.56073
103.14618 172.02382 378.13943 366.38678 155.37381 108.64426 300.18518 400.0
250.05157 108.67917 199.71655 366.32098 344.7071 172.11243 121.80669
280.45807 396.87512 270.48798 101.40578 180.93207 383.15262 359.67145
147.66635 112.39021 309.69543 399.65524 239.83597 105.582504 209.45882
372.50076 336.56537 163.5629 127.40871 290.3911 394.45953 260.31952
100.35539 190.16055 387.54724 352.44757 140.43495 116.77568 318.92953
398.6156 229.66756  ]
tk> scrollbar .cv-scroller.hscroll -command ".cv-scroller.test-canvas xview"
-orient "horizontal"
tk> scrollbar .cv-scroller.vscroll -command ".cv-scroller.test-canvas yview"
-orient "vertical"
tk> frame .f76 -padx 0 -pady 0 -class frame
tk> frame .f76.f79 -borderwidth 2 -padx 0 -pady 0 -relief sunken -class
frame
tk> label .f76.f79.lbl96 -text "Rotation:"
tk> button .f76.f79.b97 -text "Start" -command {callback ".f76.f79.b97.CMD"}
tk> button .f76.f79.b98 -text "Stop" -command {callback ".f76.f79.b98.CMD"}
tk> button .f76.b80 -text "Hallo" -command {callback ".f76.b80.CMD"}
tk> button .f76.b81 -text "Welt!" -command {callback ".f76.b81.CMD"}
tk> frame .f76.f82 -borderwidth 2 -padx 0 -pady 0 -relief sunken -class
frame
tk> label .f76.f82.lbl99 -text "Test:"
tk> button .f76.f82.b100 -text "OK:" -command {callback ".f76.f82.b100.CMD"}
tk> entry .f76.point-ct -background systembuttonface -textvariable
".f76.point-ct"
tk> button .f76.b83 -text "Print" -command {callback ".f76.b83.CMD"}
tk> button .f76.b84 -text "Reset" -command {callback ".f76.b84.CMD"}
tk> menu .cv-scroller.test-canvas.bkg-pop -tearoff 0
tk> .mnu75 add cascade -menu ".mnu75.mnu78" -label "File"
tk> .mnu75.mnu78 add command -command {callback "..MNU90"} -label "Load"
tk> .mnu75.mnu78 add command -command {callback "..MNU91"} -label "Save"
-state normal
tk> .mnu75.mnu78 add separator
tk> .mnu75.mnu78 add cascade -menu ".mnu75.mnu78.mnu92" -label "Export..."
tk> .mnu75.mnu78 add separator
tk> .mnu75.mnu78 add command -accelerator "Alt-q" -command "exit" -label
"Quit" -underline 1
tk> .mnu75.mnu78.mnu92 add command -command {callback "..MNU101"} -label
"jpeg"
tk> .mnu75.mnu78.mnu92 add command -command {callback "..MNU102"} -label
"png"
tk> .cv-scroller.test-canvas.bkg-pop add radiobutton -variable ".cv-
scroller.test-canvas.bkg-pop.bkg" -value "red" -command {callback ".cv-
scroller.test-canvas.bkg-pop.0.CMD"} -label "Crimson Tide"
tk> .cv-scroller.test-canvas.bkg-pop add radiobutton -variable ".cv-
scroller.test-canvas.bkg-pop.bkg" -value "yellow" -command {callback ".cv-
scroller.test-canvas.bkg-pop.1.CMD"} -label "Oak Tree Ribbon"
tk> .cv-scroller.test-canvas.bkg-pop add radiobutton -variable ".cv-
scroller.test-canvas.bkg-pop.bkg" -value blue -command {callback ".cv-
scroller.test-canvas.bkg-pop.2.CMD"} -label "Sky"
tk> .cv-scroller.test-canvas.bkg-pop add radiobutton -variable ".cv-
scroller.test-canvas.bkg-pop.bkg" -value systembuttonface -command {callback
".cv-scroller.test-canvas.bkg-pop.3.CMD"} -label "Factory"
tk> set .f76.point-ct "42"
tk> set .cv-scroller.test-canvas.bkg-pop.bkg
tk> bind . <Alt-q> {.mnu75.mnu78 invoke 5}
tk> trace add variable .f76.point-ct write "trc2 .f76.point-ct.TRACEWRITE"
tk> . configure -menu .mnu75
tk> grid .cv-scroller.test-canvas -row 0 -column 0 -sticky news
tk> grid .cv-scroller.hscroll -row 1 -column 0 -sticky we
tk> grid .cv-scroller.vscroll -row 0 -column 1 -sticky ns
tk> grid columnconfigure .cv-scroller 0 -weight {1}
tk> grid columnconfigure .cv-scroller 1 -weight {0}
tk> grid rowconfigure .cv-scroller 0 -weight {1}
tk> grid rowconfigure .cv-scroller 1 -weight {0}
tk> pack .f76.f79.lbl96 .f76.f79.b97 .f76.f79.b98 -side left -anchor nw
-padx 0 -pady 0
tk> pack .f76.f82.lbl99 .f76.f82.b100 -side left -anchor nw -padx 0 -pady 0
tk> pack .f76.f79 .f76.b80 .f76.b81 .f76.f82 .f76.point-ct .f76.b83 .f76.b84
-side left -anchor nw -padx 0 -pady 0
tk> pack .cv-scroller -side top -fill both -expand 1
tk> pack .f76 -side bottom
tk> .cv-scroller.test-canvas configure -xscrollcommand ".cv-scroller.hscrollset"
tk> .cv-scroller.test-canvas configure -yscrollcommand ".cv-scroller.vscrollset"
tk> wm deiconify .
tk> tk_popup .cv-scroller.test-canvas.bkg-pop 120 212

ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060405/2fe24096/attachment.html>

From fgoenninger at prion.de  Fri Apr  7 22:26:13 2006
From: fgoenninger at prion.de (Frank Goenninger)
Date: Sat, 8 Apr 2006 00:26:13 +0200
Subject: [cells-devel] Celtk on ACL80 running on an MacBook Pro ...
Message-ID: <F9EF0922-EAAB-44E4-8748-0B5436A024D1@prion.de>

Kenny, fellow Cells Users,

Just to show that in you can do it principle here's a screenshot  
showing the result of running Celtk / Cells kicked off by (ctk::tk- 
test) in AllegroCL 8.0 on my brand new MacBook Pro ... Of course,  
there's other apps available also ;-)


Have fun - and yes, ACL is running sloooooowww ... (Rosetta obviously  
keeping both cores of the Intel CPU busy at 80% load level ...)

Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: celtk-ltk-test-on-macbook-pro-with-acl80.tiff
Type: image/tiff
Size: 482992 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060408/00c22f37/attachment.tiff>
-------------- next part --------------



From kentilton at gmail.com  Fri Apr  7 22:41:53 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Fri, 7 Apr 2006 18:41:53 -0400
Subject: [cells-devel] Celtk on ACL80 running on an MacBook Pro ...
In-Reply-To: <F9EF0922-EAAB-44E4-8748-0B5436A024D1@prion.de>
References: <F9EF0922-EAAB-44E4-8748-0B5436A024D1@prion.de>
Message-ID: <a44bc6a10604071541h1e216b2dg517cb89b6e13d2c4@mail.gmail.com>

Cool, thx. If you are a glutton for punishment you can update from cvs and
get the new version. It uses the number to change the number of lines drawn
in the spinning shape. And the popup menu (click the canvas) lets you set
the background color. uh, perhaps the more valuable result would be getting
the new doc I wrote as I revised the demo. I mean, how often does kenny
write doc?!

:)

ken

On 4/7/06, Frank Goenninger <fgoenninger at prion.de> wrote:
>
> Kenny, fellow Cells Users,
>
> Just to show that in you can do it principle here's a screenshot
> showing the result of running Celtk / Cells kicked off by (ctk::tk-
> test) in AllegroCL 8.0 on my brand new MacBook Pro ... Of course,
> there's other apps available also ;-)
>
>
> Have fun - and yes, ACL is running sloooooowww ... (Rosetta obviously
> keeping both cores of the Intel CPU busy at 80% load level ...)
>
> Frank
>
>
>
>
>
>
>
> _______________________________________________
> cells-devel site list
> cells-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060407/979346ff/attachment.html>

From jdunrue at gmail.com  Sun Apr  9 18:43:39 2006
From: jdunrue at gmail.com (Jack Unrue)
Date: Sun, 9 Apr 2006 12:43:39 -0600
Subject: [cells-devel] initial stab at using Cells
Message-ID: <d3df77800604091143x3ff05d8embf09d7c7fae80cbf@mail.gmail.com>

Well, I've gotten through my first round of experimenting with
Cells, and I have to say I like it a lot. If you want to see some
code, take a look at:

http://common-lisp.net/websvn/filedetails.php?repname=graphic-forms&path=%2Ftrunk%2Fsrc%2Fdemos%2Funblocked%2Funblocked-model.lisp&rev=0&sc=0

which is the data model for a simple game where you click
on blocks to score points (and where the remaining blocks
fall down to fill in the hole(s)). The game gets progressively
harder as you pass from one level to the next. The UI displays
the current level, current score, and points needed for the
next level. Screenshot here:

http://sourceforge.net/project/screenshots.php?group_id=163034&ssid=31548

If you look at the model, there is a shape-data slot that really
ought to be ephemeral based on how the score slot's formula
depends on it (the 'shape' score should only be added to the
overall score tally once, no matter how many times the UI asks
for the score). But I was seeing some intermittent behavior
where it seemed like the shape-data value had already been
propagated (and thus cleared) by the time that my UI code asked
for the score. So I took the :ephemeral attribute off until I get some
more time to figure that out. I'm sure this is a bug in my understanding,
not in Cells.

It would be good to document some typical strategies for dealing
with self-referential slots (circularity) but in thinking about how I
would describe what I did, I can see how it would be hard to explain
to someone else :-)

--
Jack Unrue


From jdunrue at gmail.com  Sun Apr  9 18:12:30 2006
From: jdunrue at gmail.com (Jack Unrue)
Date: Sun, 9 Apr 2006 12:12:30 -0600
Subject: [cells-devel] tiny patch for running Cells 3 on CLISP
In-Reply-To: <a44bc6a10604011343i292faabcw6242190e52cc7a16@mail.gmail.com>
References: <d3df77800604010810j175cbf44j9c9acf0fac276b36@mail.gmail.com>
	<a44bc6a10604011343i292faabcw6242190e52cc7a16@mail.gmail.com>
Message-ID: <d3df77800604091112q157dacefld2fac813ba06ed75@mail.gmail.com>

On 4/1/06, Ken Tilton <kentilton at gmail.com> wrote:
>
> On 4/1/06, Jack Unrue <jdunrue at gmail.com> wrote:
> > Hello Kenny,
> >
> > As of CLISP 2.38 (if not earlier, I haven't checked), the
> > #+clisp defun for slot-definition-name is no longer necessary.
>
>
> Aha! I spotted that when cleaning up the code and had a feeling it could go.
> Thanks for the patch.

Sorry I didn't catch this before, but you also need these
changes for clisp (also tested on LW):

===================================================================
RCS file: /project/cells/cvsroot/cells/model-object.lisp,v
retrieving revision 1.4
diff -r1.4 model-object.lisp
53c53
<       for sn = (slot-definition-name esd)
---
>       for sn = (clos::slot-definition-name esd)
115,116c115,116
<     (when (md-slot-cell-type (type-of self) (slot-definition-name esd))
<       (let* ((slot-name (slot-definition-name esd))
---
>     (when (md-slot-cell-type (type-of self) (clos::slot-definition-name esd))
>       (let* ((slot-name (clos::slot-definition-name esd))

===================================================================
RCS file: /project/cells/cvsroot/cells/cells-test/test.lisp,v
retrieving revision 1.4
diff -r1.4 test.lisp
228c228
<                    for sn = (slot-definition-name esd)
---
>                    for sn = (clos::slot-definition-name esd)

--
Jack Unrue


From kentilton at gmail.com  Mon Apr 10 02:38:27 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Sun, 9 Apr 2006 22:38:27 -0400
Subject: [cells-devel] initial stab at using Cells
In-Reply-To: <d3df77800604091143x3ff05d8embf09d7c7fae80cbf@mail.gmail.com>
References: <d3df77800604091143x3ff05d8embf09d7c7fae80cbf@mail.gmail.com>
Message-ID: <a44bc6a10604091938g1b483c78xc0802f31e9389107@mail.gmail.com>

On 4/9/06, Jack Unrue <jdunrue at gmail.com> wrote:
>
> Well, I've gotten through my first round of experimenting with
> Cells, and I have to say I like it a lot. If you want to see some
> code, take a look at:
>
>
> http://common-lisp.net/websvn/filedetails.php?repname=graphic-forms&path=%2Ftrunk%2Fsrc%2Fdemos%2Funblocked%2Funblocked-model.lisp&rev=0&sc=0
>
> which is the data model for a simple game where you click
> on blocks to score points (and where the remaining blocks
> fall down to fill in the hole(s)). The game gets progressively
> harder as you pass from one level to the next. The UI displays
> the current level, current score, and points needed for the
> next level. Screenshot here:
>
> http://sourceforge.net/project/screenshots.php?group_id=163034&ssid=31548
>
> If you look at the model, there is a shape-data slot that really
> ought to be ephemeral based on how the score slot's formula
> depends on it (the 'shape' score should only be added to the
> overall score tally once, no matter how many times the UI asks
> for the score). But I was seeing some intermittent behavior
> where it seemed like the shape-data value had already been
> propagated (and thus cleared) by the time that my UI code asked
> for the score. So I took the :ephemeral attribute off until I get some
> more time to figure that out. I'm sure this is a bug in my understanding,
> not in Cells.
>
> It would be good to document some typical strategies for dealing
> with self-referential slots (circularity) but in thinking about how I
> would describe what I did, I can see how it would be hard to explain
> to someone else :-)



it is pretty clear to me as an old Cells hand. I am toast right now, but
I'll send some comments tomorrow. One Q: where does game-shape-data get
called, in some imperative logic responding to events,  that detects that a
shape has been placed?

ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060409/1aadc561/attachment.html>

From jdunrue at gmail.com  Mon Apr 10 03:32:21 2006
From: jdunrue at gmail.com (Jack Unrue)
Date: Sun, 9 Apr 2006 21:32:21 -0600
Subject: [cells-devel] initial stab at using Cells
In-Reply-To: <a44bc6a10604091938g1b483c78xc0802f31e9389107@mail.gmail.com>
References: <d3df77800604091143x3ff05d8embf09d7c7fae80cbf@mail.gmail.com>
	<a44bc6a10604091938g1b483c78xc0802f31e9389107@mail.gmail.com>
Message-ID: <d3df77800604092032p57867dd4kb12a844d76a14e2d@mail.gmail.com>

On 4/9/06, Ken Tilton <kentilton at gmail.com> wrote:
>
> it is pretty clear to me as an old Cells hand. I am toast right now, but
> I'll send some comments tomorrow. One Q: where does game-shape-data get
> called, in some imperative logic responding to events,  that detects that a
> shape has been placed?

In tiles-panel.lisp, look for gfw:event-mouse-up. Basically if the location
of the mouse up occurs within the same tile shape as the mouse down that
started the selection, then the list of points comprising that shape become
the input data that tickles the game model. The internal representation
of the board gets modified accordingly (the selected shape is removed
and points are awarded), then the scoreboard and tile panels are told
to redraw themselves via observers on the score and tiles slots.

Thanks for taking a look.

--
Jack Unrue


From kentilton at gmail.com  Mon Apr 10 12:48:32 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Mon, 10 Apr 2006 08:48:32 -0400
Subject: [cells-devel] initial stab at using Cells
In-Reply-To: <d3df77800604092032p57867dd4kb12a844d76a14e2d@mail.gmail.com>
References: <d3df77800604091143x3ff05d8embf09d7c7fae80cbf@mail.gmail.com>
	<a44bc6a10604091938g1b483c78xc0802f31e9389107@mail.gmail.com>
	<d3df77800604092032p57867dd4kb12a844d76a14e2d@mail.gmail.com>
Message-ID: <443A5420.2070805@gmail.com>

Jack Unrue wrote:

>On 4/9/06, Ken Tilton <kentilton at gmail.com> wrote:
>  
>
>>it is pretty clear to me as an old Cells hand. I am toast right now, but
>>I'll send some comments tomorrow. One Q: where does game-shape-data get
>>called, in some imperative logic responding to events,  that detects that a
>>shape has been placed?
>>    
>>
>
>In tiles-panel.lisp, look for gfw:event-mouse-up. Basically if the location
>of the mouse up occurs within the same tile shape as the mouse down that
>started the selection, then the list of points comprising that shape become
>the input data that tickles the game model.
>
Ok. One thing that might pay off in more elaborate (as in reall-world) 
models is to move as much semantics as possible into the Cells realm. In 
this case you might just have the event handler do:

   (setf (clicked shape) t)

...where clicked is ephemeral. Then elsewhere some other ephemeral 
"new-points-earned" ephemeral converts that to points, while other cells 
might worry about a sound to be generated or graphic transformations to 
apply. In my GUIs I go further and get mouse-downs and mouse-ups into 
the game. Since I am usually rolling my own GUI, I need this to do the 
higlighting changes as mouse-down, mouse-over, and mouse-up events go 
by. IIRC, in Cello I even created a class called mouse-click, which came 
into existence on mouse-down (remembering on which GUI element if any 
the mousedown happened) and then expired on mouseup. anyway, what you 
did is fine, just offering food for thought if you kepe going with cells.

> The internal representation
>of the board gets modified accordingly (the selected shape is removed
>and points are awarded), then the scoreboard and tile panels are told
>to redraw themselves via observers on the score and tiles slots.
>  
>
Yep. Again, if one wants to go a little further one can have ruled cells 
for appearance that watched other cells for score and and other game 
state. The nice thing here is that there are only so many (tho quite a 
few) cells that affect screen draws. Once all those have observers that 
call the "update me" function, yer done. From now on one just rights 
rules connecting appearance to program state and it all Just Works. 
(btw, in this case the "update me" function is merely flagging things 
for update, otherwise it gets done repeatedly as dozens of appearance 
cells decide they have changed.

kt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060410/d80ea716/attachment.vcf>

From kentilton at gmail.com  Mon Apr 10 20:19:09 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Mon, 10 Apr 2006 16:19:09 -0400
Subject: [cells-devel] initial stab at using Cells
In-Reply-To: <d3df77800604100958h7ab42b89pbd7a33c079319770@mail.gmail.com>
References: <d3df77800604091143x3ff05d8embf09d7c7fae80cbf@mail.gmail.com>
	<a44bc6a10604100900gaedb923r1b30df2623412b2b@mail.gmail.com>
	<d3df77800604100958h7ab42b89pbd7a33c079319770@mail.gmail.com>
Message-ID: <a44bc6a10604101319s5b72255ckd98c887b19fcc2c6@mail.gmail.com>

On 4/10/06, Jack Unrue <jdunrue at gmail.com> wrote:
>
> I feel the need to strike the right balance between UI/logic separation
> vs. taking full advantage of Cells.


Oh, if you are big on separation maybe you can confirm something I suspect,
namely that Cells, by allowing different instances of the same class to have
different rules for the same slot, makes OO design.

For example, one can have a game normally look like:

   (make-instance 'game
        :speed (c? (* (^difficulty-slider) 500))...

But then for debugging a hard problem you might want to play back a log at
full speed and so the replay code goes:

   (make-instance 'game :speed 500...

In the first case the game /instance/ is being driven by the GUI slider
widget, but the game /class/ does not know about the GUI.

Does that make sense in resolving the separation issue?

ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060410/e125b6e3/attachment.html>

From jdunrue at gmail.com  Tue Apr 11 04:23:59 2006
From: jdunrue at gmail.com (Jack Unrue)
Date: Mon, 10 Apr 2006 22:23:59 -0600
Subject: [cells-devel] initial stab at using Cells
In-Reply-To: <a44bc6a10604101319s5b72255ckd98c887b19fcc2c6@mail.gmail.com>
References: <d3df77800604091143x3ff05d8embf09d7c7fae80cbf@mail.gmail.com>
	<a44bc6a10604100900gaedb923r1b30df2623412b2b@mail.gmail.com>
	<d3df77800604100958h7ab42b89pbd7a33c079319770@mail.gmail.com>
	<a44bc6a10604101319s5b72255ckd98c887b19fcc2c6@mail.gmail.com>
Message-ID: <d3df77800604102123g7d4f28f5u370434a342585bc1@mail.gmail.com>

On 4/10/06, Ken Tilton <kentilton at gmail.com> wrote:
>
> Oh, if you are big on separation maybe you can confirm something
> I suspect, namely that Cells, by allowing different instances of
> the same class to have different rules for the same slot, makes
> OO design.
>
> For example, one can have a game normally look like:
>
>    (make-instance 'game
>         :speed (c? (* (^difficulty-slider) 500))...
>
> But then for debugging a hard problem you might want to play back
> a log at full speed and so the replay code goes:
>
>    (make-instance 'game :speed 500...
>
> In the first case the game /instance/ is being driven by the GUI
> slider widget, but the game /class/ does not know about the GUI.
>
> Does that make sense in resolving the separation issue?

I'm going to assume a certain interpretation of your example that you
might not have actually intended, so if you didn't mean that the value
of (^difficulty-slider) is literally a Cells wrapper around a slider
or some specific widget type, then please by all means correct me. And
thus ignore the rest of this and just know that we'd be totally
agreeing :-)

So at the risk of preaching to the choir...

I'm not too far out of disagreement with you, but consider a slightly
different arrangement. In the above example, rename
(^difficulty-slider) to something like (^difficulty-selector). What
the renamed slot now indicates is that the "difficulty" value is still
user input but we don't specify what UI is actually used to implement
that -- it's just some mechanism for which the game logic doesn't need
to know the specifics. And at the same time, change the formula
associated with the difficulty-selector such that it's not directly
tied anymore to any particular widget type. The game UI code is
obviously responsible for translating widget events into values posted
to this selector model. So, in some respects, the name change seems
pedantic, but it's an important part of the abstraction.

By not pre-supposing what control is actually driving that slot, you
get some freedom to make UI changes that (within reason) won't affect
this game logic. For example, in version 1 the difficulty setting is a
slider, but after usability testing you realize that a slider is too
granular, and users are better served if it's just three radio
buttons. The UI code would change such that (^difficulty-selector)
values are now posted by code that manages the radio buttons, but the
game logic remain unchanged.

This facilitates the same sort of debug-mode hardcoding of the
difficulty value, again without requiring a change to the game
logic. The debug value is just another form of user input, albeit a
hard-coded value where the user is actually the programmer trying to
debug a problem.

Really, I'd bet this isn't too far from the concept you have in mind,
I'm just saying that we can abstract that a bit further. Again, that's
if I'm interpreting you correctly.

--
Jack Unrue


From kentilton at gmail.com  Tue Apr 11 04:56:13 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Tue, 11 Apr 2006 00:56:13 -0400
Subject: [cells-devel] initial stab at using Cells
In-Reply-To: <d3df77800604102123g7d4f28f5u370434a342585bc1@mail.gmail.com>
References: <d3df77800604091143x3ff05d8embf09d7c7fae80cbf@mail.gmail.com>
	<a44bc6a10604100900gaedb923r1b30df2623412b2b@mail.gmail.com>
	<d3df77800604100958h7ab42b89pbd7a33c079319770@mail.gmail.com>
	<a44bc6a10604101319s5b72255ckd98c887b19fcc2c6@mail.gmail.com>
	<d3df77800604102123g7d4f28f5u370434a342585bc1@mail.gmail.com>
Message-ID: <443B36ED.9050206@gmail.com>

Jack Unrue wrote:

>On 4/10/06, Ken Tilton <kentilton at gmail.com> wrote:
>  
>
>>Oh, if you are big on separation maybe you can confirm something
>>I suspect, namely that Cells, by allowing different instances of
>>the same class to have different rules for the same slot, makes
>>OO design.
>>
>>For example, one can have a game normally look like:
>>
>>   (make-instance 'game
>>        :speed (c? (* (^difficulty-slider) 500))...
>>
>>But then for debugging a hard problem you might want to play back
>>a log at full speed and so the replay code goes:
>>
>>   (make-instance 'game :speed 500...
>>
>>In the first case the game /instance/ is being driven by the GUI
>>slider widget, but the game /class/ does not know about the GUI.
>>
>>Does that make sense in resolving the separation issue?
>>    
>>
>
>I'm going to assume a certain interpretation of your example that you
>might not have actually intended, so if you didn't mean that the value
>of (^difficulty-slider) is literally a Cells wrapper around a slider
>or some specific widget type, then please by all means correct me. And
>thus ignore the rest of this and just know that we'd be totally
>agreeing :-)
>
>So at the risk of preaching to the choir...
>
>I'm not too far out of disagreement with you, but consider a slightly
>different arrangement. In the above example, rename
>(^difficulty-slider) to something like (^difficulty-selector). What
>the renamed slot now indicates is that the "difficulty" value is still
>user input but we don't specify what UI is actually used to implement
>that -- it's just some mechanism for which the game logic doesn't need
>to know the specifics. And at the same time, change the formula
>associated with the difficulty-selector such that it's not directly
>tied anymore to any particular widget type. The game UI code is
>obviously responsible for translating widget events into values posted
>to this selector model. So, in some respects, the name change seems
>pedantic, but it's an important part of the abstraction.
>
>By not pre-supposing what control is actually driving that slot, you
>get some freedom to make UI changes that (within reason) won't affect
>this game logic. For example, in version 1 the difficulty setting is a
>slider, but after usability testing you realize that a slider is too
>granular, and users are better served if it's just three radio
>buttons. 
>
Exactly what I had in mind. I actually should have given:

     (md-value (widget-named :game-difficulty))

Then the slider is named :game-difficulty and the md-values range from 0 
to 1. The rule does not have to change if :game-difficulty becomes a 
radio-group container widget of three radio buttons easy, average, and 
hard as long as the radio-group rule for md-value translates the 
selection to 0.33, 0.66, and 1.0 or something like that.

But I am going further and saying there is not much harm in having the 
radio-group just take on the symbolic values 'easy, 'average, and 'hard 
because we can then change the code to:

    (make-instance 'game :difficulty (c? (ecase (md-value (widget-named 
:game-diificulty)) (easy 0.333)...etc

ie, the ability to tailor instances with rules vs mere literal values 
such as 0.333, 0.555 makes decoupling less urgent. The developer just 
has to arrange at some point for the game difficulty to resolve to a 
value between zero and one.

ken


-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060411/8b21acb9/attachment.vcf>

From fgoenninger at prion.de  Wed Apr 12 20:38:25 2006
From: fgoenninger at prion.de (Frank Goenninger)
Date: Wed, 12 Apr 2006 22:38:25 +0200
Subject: [cells-devel] Re: Celtk/Cells: Need a little help...
In-Reply-To: <443D627A.6010107@gmail.com>
References: <01680BBB-51CD-4E9E-AB4F-EB4C760B062C@mac.com>
	<443D627A.6010107@gmail.com>
Message-ID: <0DD5E4AD-A0B0-4D6A-B34F-7AC0DDF32FA3@prion.de>


Am 12.04.2006 um 22:26 schrieb Ken Tilton:

>
>>
>>                      (setf (pb-state (fm^ :oper-mode-pb)) ;; FRGO:  
>> HERE !!!
>>                           (on-off-toggle
>>                             (fm^v :oper-mode-pb))))))  ;; FRGO:  
>> HERE !!!
>
>
> (mk-menu-entry-command
>                :label "Action: Push the OPER MODE button"
>                        :command (c? (tk-callback .tkw 'push-oper- 
> mode-pb
>                       (lambda ()
>                     (setf (fm^v :oper-mode-pb) ;; FRGO: HERE !!!
>                          (on-off-toggle
>                            (fm^v :oper-mode-pb))))))  ;; FRGO:  
> HERE !!!
>             )
>
> We have three slots in play now: .md-value, enabled, and pb- 
> state. .md-value because fm^v expands to (md-value (fm^ ...))
>
> As the ltktest-cells-inside doc says, I like to use the slot md- 
> value of an instance the same way TK treats the name of an instance  
> as a variable, namely to hold the key value that instance  
> represents in the application.
>
> It is not clear to me that enabled is that slot, even tho you have  
> the pb-state initarg associated with it. I would think that pb- 
> state is currently playing the key role of holding the key on/off  
> value. This is confirmed by you setting the toggle result into pb- 
> state.
>
> On the other hand, I see pb-state is ephemeral. I also see:
>
> (defmacro push-the-button (button-id)
>  `(setf (fm^v ,button-id) :pressed))
>
> Now there you are setting the md-value to :pressed, but since I see  
> toggle intentions, I am guessing this is a button that gets pressed  
> and then released then pressed again, and the second time produces  
> the opposite value as the first. So, putting it all together (and  
> throwing out altogether enabled since I see that is not yet  
> implemented):
>
> (defmodel pushbutton (application-object)
>  ((.md-value :cell t :accessor pb-state :initform (c-in :off))))
>
> (mk-menu-entry-command
> :label "Action: Push the OPER MODE button"
> :command (c? (tk-callback .tkw 'push-oper-mode-pb
>                (lambda ()
>                  (setf (fm^v :oper-mode-pb)
>                    (on-off-toggle
>                     (fm^v :oper-mode-pb)))))))
>
> If you want to get a little fancier:
>
> (defmodel pushbutton (application-object)
>  ((.md-value :cell t :accessor pb-state
>     :initform (c? (if (^pressed)
>                       (on-off-toggle .cache)
>                     (initial-pb-state self))))
>   (pressed :cell :ephemeral :intiform (c-in nil) ... etc)
>   (initial-pb-state :cell nil ....etc )))
>
> (mk-menu-entry-command
> :label "Action: Push the OPER MODE button"
> :command (c? (tk-callback .tkw 'push-oper-mode-pb
>                (lambda ()
>                  (setf (pressed (fm^ :oper-mode-pb)) t)))))
>
> The latter can be good for doing things like associating a click  
> sound with the button press, because then you just have other cells  
> watching (^pressed). Otherwise you end up loading more and more  
> code into the menu callback.
>
> hth, ken

You wonder if this helps? You just not only discovered some bugs but  
also explained to me .cache and real use of .md-value ...

It certainly helps!!

Thanks so much.

Frank



From fgoenninger at prion.de  Thu Apr 13 17:47:56 2006
From: fgoenninger at prion.de (Frank Goenninger)
Date: Thu, 13 Apr 2006 19:47:56 +0200
Subject: [cells-devel] Celtk/cells: timing issue in initialization and No
	Widgets :-(
Message-ID: <63A8B78A-7D99-4E99-AD3C-212970B54BFE@prion.de>

Hi Kenny and fellow

I've been enhancing my power supply remote control app with some  
widgets to enter the RS232C/USB port name. Only issue I have is I  
don't see any error but no widgets appearing... Seems to be a simple  
one... HELP!

Another, more serious thing in my eyes , is the issue I have with my  
different instances getting initialized. I have marked the  
challenging place in the code with
  <<< frgo: HERE - see :tk-fill ...

Issue is that the object darc-rs232c-port does not seem to be  
finalized yet when the function darc-setup-panel gets called. So I  
cannot depend a text label on a cell slot of the darc-rs232c-port  
object...

I tried to avoid this with some clumsy code but it seems simply to be  
wrong. Can't get my head to find another solution. Any input here of  
course very welcome!!

Thx again!

Frank

-----


(in-package :cl-user)

(eval-when (:load-toplevel :compile-toplevel :execute)
#+asdf (progn
     #-cells (asdf:operate 'asdf:load-op :cells)
     #-Celtk (asdf:operate 'asdf:load-op :Celtk)
))

(in-package :celtk-user)

(defparameter *psu-rc-app* nil
   "The instance of the PSU Remote Control application.")

;; BASE CLASS FOR APPLICATIONS

(defmodel application ()
   (( .md-value :cell t :accessor view   :initform (c-in  
nil)       :initarg :view )
    ( name   :cell t :accessor name   :initform (c-in  
nil)       :initarg :name )
    ( status :cell t :accessor status :initform (c- 
in :disabled) :initarg :status)
   ))

;(defmethod initialize-instance :after ((self application) &key)
;  (incf (nr-instances self))) - does not work ...

(defmodel application-object (family)
   (( .md-name :cell t :accessor id :initform (c- 
in :unknown) :initarg :id )))

;; PUSHBUTTON, SIGNAL-LAMP, PUSHBUTTON-WITH-SIGNAL-LAMP MODELS

(defmodel pushbutton (application-object)
   (( .md-value :cell t
	       :accessor pb-state
	       :initform (c? (if (^pressed)
				   (on-off-toggle .cache)
				 (initial-pb-state self)))
	       :initarg :pb-state )
    ( initial-pb-state :cell nil
		      :initform :off
		      :initarg :initial-pb-state
		      :reader initial-pb-state )
    ( pressed :cell :ephemeral
	     :accessor pressed
	     :initform (c-in nil))))

(defmacro mk-pushbutton (&rest initargs)
   `(make-instance 'pushbutton
		  :fm-parent *parent*
		  , at initargs))

;(defmacro push-the-button (button-id)
;  `(setf (fm^v ,button-id) :pressed))

(defmodel signal-lamp (application-object)
   ((lamp-state :cell t
	       :accessor lamp-state
	       :initform (c? (if (^switched)
				   (not .cache)
				 (initial-lamp-state self)))
	       :initarg :lamp-state )
    ( initial-lamp-state :cell nil
		        :initform :off
		        :initarg :initial-lamp-state
		        :reader initial-lamp-state )
    ( switched :cell :ephemeral
	      :accessor switched
	      :initform (c-in nil))))

(defmacro mk-signal-lamp (&rest initargs)
   `(make-instance 'signal-lamp
		  :fm-parent *parent*
		  , at initargs))

(defmodel pushbutton-with-signal-lamp (pushbutton signal-lamp)
   ())

(defmacro mk-pushbutton-with-signal-lamp (&rest initargs)
   `(make-instance 'pushbutton-with-signal-lamp
		  :fm-parent *parent*
		  , at initargs))

;; PSU-APP-RC MODEL

(defun control-panel ()
   (list
     ;; SIGNAL LAMPS

     ;; Mains signal lamp
     (mk-signal-lamp :id :mains-lamp
		    ;:lamp-state (cr-mains-lamp-state)
		    )

     ;; OPER signal lamp
     (mk-signal-lamp :id :oper-lamp
		    ;:lamp-state (cr-oper-lamp-state)
		    )

     ;; TEST signal lamp
     (mk-signal-lamp :id :test-lamp
		    ;:lamp-state (cr-test-lamp-state)
		    )

     ;; FAIL signal lamp
     (mk-signal-lamp :id :fail-lamp
		    ;:lamp-state (cr-fail-lamp-state)
		    )
     ;; PUSH BUTTONS AND LAMPS

     ;; Oper mode pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :oper-mode-pb
				    :initial-pb-state :off
				    :lamp-state (c? (if (^pressed)
							  (^pb-state)
							(initial-lamp-state self)))
				    )

     ;; Test mode pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :test-mode-pb
				    :initial-pb-state :off
				    ;:lamp-state (c? (^pb-state))
				    )

     ;; Ua-enable pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :Ua-enable-pb
				    :initial-pb-state :off)

     ;; Ug1 pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :Ug1-pb
				    :initial-pb-state :off)

     ;; Ug2 pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :Ug2-pb
				    :initial-pb-state :off)

     ;; Uh pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :Uh-pb
	                            :initial-pb-state :off)

     ;; Uh pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :Uh-pb
	                            :initial-pb-state :off)
   )
)

(defmodel psu-rc-app (application)
   (
     ;; Mains status (may have several vaklues, :ok indicates OK ;-)
     ( mains-status :cell t :accessor mains-status :initform (c-in nil)
		   :initarg :mains-status )

     ;; Operate status: eitehr :operate-mode  or :test-mode
     ( operate-status :cell t :accessor operate-status :initform (c- 
in nil)
		     :initarg :operate-status )

     ;; RS232C port
     ;; As soon as the port name is set try to read data from this port
     ;; DARC stands for Device and Application Remote Control
     ( darc-rs232c-port :cell t :accessor darc-rs232c-port
		       :initform (c-in nil)
		       :initarg :darc-rs232c-port )

     ;; Voltage and current values to be  
displayed                      Units
     ( Ua  :cell t :accessor Ua  :initform (c-in  
nil) :initarg :Ua )  ; [ V ]
     ( Ia  :cell t :accessor Ia  :initform (c-in  
nil) :initarg :Ia )  ; [ A ]
     ( Uh  :cell t :accessor Uh  :initform (c-in  
nil) :initarg :Uh )  ; [ V ]
     ( Ih  :cell t :accessor Ih  :initform (c-in  
nil) :initarg :Ih )  ; [ A ]
     ( Ug1 :cell t :accessor Ug1 :initform (c-in  
nil) :initarg :Ug1 ) ; [ V ]
     ( Ig1 :cell t :accessor Ig1 :initform (c-in  
nil) :initarg :Ig1 ) ; [ mA ]
     ( Ug2 :cell t :accessor Ug2 :initform (c-in  
nil) :initarg :Ug2 ) ; [ V ]
     ( Ig2 :cell t :accessor Ig2 :initform (c-in  
nil) :initarg :Ig2 ) ; [ mA ]
   )
)

(defmodel rs232c-port (window) ; needs to be a widget to get a
                                ; timer easily ;-)
   (( status :accessor status
	    :cell t
	    :initform (c-in :not-connected))
    ( device-name :accessor device-name
		 :cell t
		 :initform (c-in nil)
		 :initarg :device-name ))
   (:default-initargs
      :id :darc-port
      :timers (c? (list
		   (make-instance 'timer
				  :state (c-in :on)
				  :repeat t
				  :delay 1000 ; 1 s delay
				  :action (lambda (timer)
					     (declare (ignore timer))
					     (connect-to-darc (device-name self))))))))

(defun connect-to-darc (device-name)
   (when device-name
     (format t "~%*** Trying to connect to DARC via port ~a ...~&"  
device-name)

     ;; MISSING: Code that connects to the DARC port via USB ...
     ;; For now, just return NOT CONNECTED ...

     (values :not-connected)
   )
)

(defobserver status ((self rs232c-port))
   (format t "~%*** Status of RS232C port ~a is now ~s.~%"
	    (device-name self)
	    (status self))
   (when new-value
     (if (eq new-value :connected)
	  (setf (state (first (timers self))) :off)
         (setf (state (first (timers self))) :on)
	)))

;; HELPER FUNCTIONS

;; Toggles :on to :off and vice versa
(defun on-off-toggle (on-or-off)
   (case on-or-off
     ( :on  :off)
     ( :off :on )
     (otherwise :off))) ; Safety ! Turn off in case of unknown value  
given
                        ; (= bug in app) ...

;; PSU-RC-APP OBSERVERS

(defobserver mains-status ((self psu-rc-app))
   (format t "~%*** Mains-status is now ~s.~%" new-value))

(defobserver lamp-state ((self signal-lamp))
   (format t "~%*** Signal lamp ~a is now ~s.~%" (id self) new-value))

(defobserver pressed ((self pushbutton))
   (format t "~%*** Pushbutton ~a has been pressed (~s).~%" (id self)  
new-value))

(defobserver switched ((self signal-lamp))
   (format t "~%*** Lamp ~a has been switched (~s).~%" (id self) new- 
value))

;(defobserver pressed ((self pushbutton-with-signal-lamp))
;  (setf (switched (fm^ (md-name self)) t)))

;; Get a view / window right after making an instance
;; We only allow one instance to run !

(defmethod initialize-instance :after ((self psu-rc-app) &key)
   (when *psu-rc-app*
     (error "*** A PSU-APP-RC instance already exists. Only one  
allowed."))
   (setq *psu-rc-app* self)
   (setf (view self) (make-instance 'psu-rc-app-view))
   (setf (darc-rs232c-port self) (make-instance 'rs232c-port)))

;; PSU-RC-APP-VIEW - the view/GUI for the PSU Remote Control Application

(defmodel psu-rc-app-view (window)
   ((selected-oper-pb :cell :ephemeral :accessor selected-oper-pb
		     :initform (c-in nil) :initarg :selected-oper-pb)
    (selected-test-pb :cell :ephemeral :accessor selected-test-pb
		     :initform (c-in nil) :initarg :selected-test-pb))
   (:default-initargs
      :id :psu-rc-app-view
      :kids (c? (the-kids
		 (app-menubar)
		 (control-panel)
		 (darc-setup-panel)
		 ))))

;(defmethod initialize-instance :after ((self psu-rc-app-view) &key)
;  (tk-format '(:configure "title") "wm title . ~a" (slot-value self  
'title$)))

(defobserver title$ ((self window))
   (tk-format '(:configure "title") "wm title . ~a" (or new-value  
"Untitled")))

(defun app-menubar ()
   (mk-menubar
      :id :psu-rc-menu-bar
      :kids (c? (the-kids
		  (mk-menu-entry-cascade-ex (:label "File")
		     (mk-menu-entry-command
		        :label   "Quit"
		        :command "exit"))
		  (mk-menu-entry-cascade-ex (:label "Operate")
		     (mk-menu-entry-command
		        :label   "Set Mains Status to :OK"
			:command (c? (tk-callback .tkw 'set-mains-ok
						  (lambda () (setf (mains-status *psu-rc-app*) :ok)))))
		     (mk-menu-entry-command
		        :label "Action: Push the OPER MODE button"
                         :command (c? (tk-callback .tkw 'push-oper- 
mode-pb
				       (lambda ()
					 (setf (pressed (fm^ :oper-mode-pb)) t))))
		     )
		  )
		)
	   )
   )
)

(defun darc-setup-panel ()
   (mk-stack ()
     (mk-row ()
       (mk-label :text "DARC RS232C Port Device Name:")
       (mk-entry :id :darc-port-device-name
		:md-value (c-in "")
		:background "grey"))
     (mk-row ()
       (mk-label :text "DARC Connect Status:")
       (mk-canvas ;; <<< frgo: HERE - see :tk-fill ...
          :height 40
	 :width  40
	 :kids (c? (the-kids (mk-rectangle
			        :coords '(0 0 40 40)
				:tk-fill (c? (if (eq (if (darc-rs232c-port *psu-rc-app*) (status  
(darc-rs232c-port *psu-rc-app*))
							 nil)
						     :connected)
						   "green"
						   "red")))))))
     (mk-row ()
       (mk-label :text (c? (if (darc-rs232c-port *psu-rc-app*)
			        (status (darc-rs232c-port *psu-rc-app*))
				""))
		:relief 'sunken))))

;; (defmodel main-controls-view (canvas)
;;   ()
;;   (:default-initargs
;;       :id :main-controls-view
;;       :kids (c? (the-kids
;; 		   (

(defun run-psu-rc-app ()
   (cells-reset 'tk-user-queue-handler)
   (tk-test-class 'psu-rc-app))



From kentilton at gmail.com  Thu Apr 13 19:04:32 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Thu, 13 Apr 2006 15:04:32 -0400
Subject: [cells-devel] Re: Celtk/cells: timing issue in initialization and
	No Widgets :-(
In-Reply-To: <63A8B78A-7D99-4E99-AD3C-212970B54BFE@prion.de>
References: <63A8B78A-7D99-4E99-AD3C-212970B54BFE@prion.de>
Message-ID: <443EA0C0.7080207@gmail.com>

Frank,

I see a few things. Deets next, but first my inclination is to leave the 
problems in place and work on the core to provide helpful error messages 
where possible (I will do anything to avoid writing documentation <g>). 
This will have the advantage over documentation in that it will catch 
careless veteran mistakes as well as newby mistakes.

Issues:

1. darc-setup-panel begins:

 (defun darc-setup-panel ()
    (mk-stack ()
       <list of widgets>))

That is good in one respect, contrasted with control-panel, which begins

(defun control-panel ()
   (list
      <list-of-widgets>))

That is not absolutely the end of the world, because the-kids here:

(defmodel psu-rc-app-view (window)
  ((selected-oper-pb :cell :ephemeral :accessor selected-oper-pb
     :initform (c-in nil) :initarg :selected-oper-pb)
   (selected-test-pb :cell :ephemeral :accessor selected-test-pb
     :initform (c-in nil) :initarg :selected-test-pb))
  (:default-initargs
      :id :psu-rc-app-view
    :kids (c? (the-kids
               (app-menubar)
               (control-panel)
               (darc-setup-panel)
               ))))

Will flatten out the list returned by control-panel. In the end, every 
component listed by control-panel becomes a top-level widget of the 
window, meaning it needs packing instructions. And this brings us to the 
problem with the darc-setup-panel: it needs packing, too.

If you use stacks and rows, their kids get default packing. But the 
toplevel widget in a window does not get default packing. I tried that, 
but it gets in the way of the parent trying to do packing if the kids 
are doing packing. To do custom packing, one first must specify nil 
values for kid-packing values, then one has to pack each kid manually. I 
would explain that more, but let's just use stacks and rows.

I do not know how you visualize the outcome, but I see two big stacks 
coming, so:

control-panel now starts:
     (mk-stack ()
         <widgets>)

and psu-rc-app-view kids becomes:
    (the-kids
        (app-menubar)
        (mk-row (:packing (c?pack-self)) ;; accept all TK  packing defaults
            (control-panel)
            (darc-setup-panel))))

btw, if you check the lotsa-widgets demo you will see it starts that 
way. My policy when working with hairy libraries (like Celtk, I admit) 
is to take some sample code, make sure it works, and then rename it 
"kennys-new-app" and change things only as I need to. That let's me 
avoid /reading/ doc. (Notice a trend?) Eventually all the original code 
is gone and I understand what remains. Anyway...

With the above changes I now get a complaint about signal-lamp not 
having a path method, and I see that that is an "application-object", 
which suggests to me that you do not want it in the GUI at all, that all 
those are part of the model. I think we are on the verge of some deep OO 
design issues here. :) Let me send this off and stare at the code some more.

kt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060413/b6e1edcd/attachment.vcf>

From fgoenninger at prion.de  Thu Apr 13 20:45:05 2006
From: fgoenninger at prion.de (Frank Goenninger)
Date: Thu, 13 Apr 2006 22:45:05 +0200
Subject: [cells-devel] Celtk/cells: No Widgets! Help!
Message-ID: <7B19F8DF-9380-4354-86E1-4CC5DEC920E8@prion.de>

Hi again ...

With substantial help I was able to get some more stuff to work as  
expected. Now I am struggling with the fact that the menubar does  
indeed have the menus I installed but the few widgets I placed into  
the window simply don't appear...

Hmm - well, yes, why?? (As always, there's a FRGO placed here and there)

How do I debug what is being sent to wish ?

Thx for any inputs.

Frank

---

;; -*- mode: Lisp; Syntax: Common-Lisp; Package: celtk-user; -*-

(in-package :cl-user)

(eval-when (:load-toplevel :compile-toplevel :execute)
#+asdf (progn
     #-cells (asdf:operate 'asdf:load-op :cells)
     #-Celtk (asdf:operate 'asdf:load-op :Celtk)
))

(in-package :celtk-user)

(defparameter *psu-rc-app* nil
   "The instance of the PSU Remote Control application.")

;; BASE CLASS FOR APPLICATIONS

(defmodel application ()
   (( .md-value :cell t :accessor view   :initform (c-in  
nil)       :initarg :view )
    ( name   :cell t :accessor name   :initform (c-in  
nil)       :initarg :name )
    ( status :cell t :accessor status :initform (c- 
in :disabled) :initarg :status)
   ))

;(defmethod initialize-instance :after ((self application) &key)
;  (incf (nr-instances self))) - does not work ...

(defmodel application-object (family)
   (( .md-name :cell t :accessor id :initform (c- 
in :unknown) :initarg :id )))

;; PUSHBUTTON, SIGNAL-LAMP, PUSHBUTTON-WITH-SIGNAL-LAMP MODELS

(defmodel pushbutton (application-object)
   (( .md-value :cell t
	       :accessor pb-state
	       :initform (c? (if (^pressed)
				   (on-off-toggle .cache)
				 (initial-pb-state self)))
	       :initarg :pb-state )
    ( initial-pb-state :cell nil
		      :initform :off
		      :initarg :initial-pb-state
		      :reader initial-pb-state )
    ( pressed :cell :ephemeral
	     :accessor pressed
	     :initform (c-in nil))))

(defmacro mk-pushbutton (&rest initargs)
   `(make-instance 'pushbutton
		  :fm-parent *parent*
		  , at initargs))

;(defmacro push-the-button (button-id)
;  `(setf (fm^v ,button-id) :pressed))

(defmodel signal-lamp (application-object)
   ((lamp-state :cell t
	       :accessor lamp-state
	       :initform (c? (if (^switched)
				   (not .cache)
				 (initial-lamp-state self)))
	       :initarg :lamp-state )
    ( initial-lamp-state :cell nil
		        :initform :off
		        :initarg :initial-lamp-state
		        :reader initial-lamp-state )
    ( switched :cell :ephemeral
	      :accessor switched
	      :initform (c-in nil))))

(defmacro mk-signal-lamp (&rest initargs)
   `(make-instance 'signal-lamp
		  :fm-parent *parent*
		  , at initargs))

(defmodel pushbutton-with-signal-lamp (pushbutton signal-lamp)
   ())

(defmacro mk-pushbutton-with-signal-lamp (&rest initargs)
   `(make-instance 'pushbutton-with-signal-lamp
		  :fm-parent *parent*
		  , at initargs))

;; PSU-APP-RC MODEL

(defun control-panel ()
   (list
     ;; SIGNAL LAMPS

     ;; Mains signal lamp
     (mk-signal-lamp :id :mains-lamp
		    ;:lamp-state (cr-mains-lamp-state)
		    )

     ;; OPER signal lamp
     (mk-signal-lamp :id :oper-lamp
		    ;:lamp-state (cr-oper-lamp-state)
		    )

     ;; TEST signal lamp
     (mk-signal-lamp :id :test-lamp
		    ;:lamp-state (cr-test-lamp-state)
		    )

     ;; FAIL signal lamp
     (mk-signal-lamp :id :fail-lamp
		    ;:lamp-state (cr-fail-lamp-state)
		    )
     ;; PUSH BUTTONS AND LAMPS

     ;; Oper mode pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :oper-mode-pb
				    :initial-pb-state :off
				    :lamp-state (c? (if (^pressed)
							  (^pb-state)
							(initial-lamp-state self)))
				    )

     ;; Test mode pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :test-mode-pb
				    :initial-pb-state :off
				    ;:lamp-state (c? (^pb-state))
				    )

     ;; Ua-enable pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :Ua-enable-pb
				    :initial-pb-state :off)

     ;; Ug1 pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :Ug1-pb
				    :initial-pb-state :off)

     ;; Ug2 pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :Ug2-pb
				    :initial-pb-state :off)

     ;; Uh pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :Uh-pb
	                            :initial-pb-state :off)

     ;; Uh pushbutton with lamp
     (mk-pushbutton-with-signal-lamp :id :Uh-pb
	                            :initial-pb-state :off)
   )
)

(defmodel psu-rc-app (application)
   (
     ;; Mains status (may have several vaklues, :ok indicates OK ;-)
     ( mains-status :cell t :accessor mains-status :initform (c-in nil)
		   :initarg :mains-status )

     ;; Operate status: eitehr :operate-mode  or :test-mode
     ( operate-status :cell t :accessor operate-status :initform (c- 
in nil)
		     :initarg :operate-status )

     ;; RS232C port
     ;; As soon as the port name is set try to read data from this port
     ;; DARC stands for Device and Application Remote Control
     ( darc-rs232c-port :cell t :accessor darc-rs232c-port
		       :initform (c-in nil)
		       :initarg :darc-rs232c-port )

     ;; Voltage and current values to be  
displayed                      Units
     ( Ua  :cell t :accessor Ua  :initform (c-in  
nil) :initarg :Ua )  ; [ V ]
     ( Ia  :cell t :accessor Ia  :initform (c-in  
nil) :initarg :Ia )  ; [ A ]
     ( Uh  :cell t :accessor Uh  :initform (c-in  
nil) :initarg :Uh )  ; [ V ]
     ( Ih  :cell t :accessor Ih  :initform (c-in  
nil) :initarg :Ih )  ; [ A ]
     ( Ug1 :cell t :accessor Ug1 :initform (c-in  
nil) :initarg :Ug1 ) ; [ V ]
     ( Ig1 :cell t :accessor Ig1 :initform (c-in  
nil) :initarg :Ig1 ) ; [ mA ]
     ( Ug2 :cell t :accessor Ug2 :initform (c-in  
nil) :initarg :Ug2 ) ; [ V ]
     ( Ig2 :cell t :accessor Ig2 :initform (c-in  
nil) :initarg :Ig2 ) ; [ mA ]
   )
)

(defmodel rs232c-port (window) ; needs to be a widget to get a
                                ; timer easily ;-)
   (( status :accessor status
	    :cell t
	    :initform (c-in :not-connected))
    ( device-name :accessor device-name
		 :cell t
		 :initform (c-in nil)
		 :initarg :device-name ))
   (:default-initargs
      :id :darc-port
      :timers (c? (list
		   (make-instance 'timer
				  :state (c-in :off)
				  :repeat t
				  :delay 10000 ; 10 s delay
				  :action (lambda (timer)
					     (declare (ignore timer))
					     (let ((status (status (darc-rs232c-port *psu-rc-app*)))
						   (device-name (device-name (darc-rs232c-port *psu-rc-app*))))
					     (if (and (eq status
							  :not-connected)
						      device-name )
					       (connect-to-darc device-name)))))))))

(defun connect-to-darc (device-name)

   (format t "~%*** connect-to-darc been called for port ~a ...~&"  
device-name)

   (when device-name
     (format t "~%*** Trying to connect to DARC via port ~a ...~&"  
device-name)

     ;; Missing: Code that connects to the DARC port via USB ...
     ;; For now, just return NOT CONNECTED ...

     :not-connected
     )
)

(defobserver status ((self rs232c-port))
   (format t "~%*** Status of RS232C port ~a is now ~s.~%"
	    (device-name self)
	    (status self))
   (when new-value
     (if (eq new-value :connected)
	  (setf (state (first (timers self))) :off)
         (setf (state (first (timers self))) :on)
	)))

;; HELPER FUNCTIONS

;; Toggles :on to :off and vice versa
(defun on-off-toggle (on-or-off)
   (case on-or-off
     ( :on  :off)
     ( :off :on )
     (otherwise :off))) ; Safety ! Turn off in case of unknown value  
given
                        ; (= bug in app) ...

;; PSU-RC-APP OBSERVERS

(defobserver mains-status ((self psu-rc-app))
   (format t "~%*** Mains-status is now ~s.~%" new-value))

(defobserver lamp-state ((self signal-lamp))
   (format t "~%*** Signal lamp ~a is now ~s.~%" (id self) new-value))

(defobserver pressed ((self pushbutton))
   (format t "~%*** Pushbutton ~a has been pressed (~s).~%" (id self)  
new-value))

(defobserver switched ((self signal-lamp))
   (format t "~%*** Lamp ~a has been switched (~s).~%" (id self) new- 
value))

;(defobserver pressed ((self pushbutton-with-signal-lamp))
;  (setf (switched (fm^ (md-name self)) t)))

;; Get a view / window right after making an instance
;; We only allow one instance to run !

(defmethod initialize-instance :after ((self psu-rc-app) &key)
   (when *psu-rc-app*
     (error "*** A PSU-APP-RC instance already exists. Only one  
allowed."))
   (setq *psu-rc-app* self)
   (setf (view self) (make-instance 'psu-rc-app-view))
   (setf (darc-rs232c-port self) (make-instance 'rs232c-port)))

;; PSU-RC-APP-VIEW - the view/GUI for the PSU Remote Control Application

(defmodel psu-rc-app-view (window)
   ((selected-oper-pb :cell :ephemeral :accessor selected-oper-pb
		     :initform (c-in nil) :initarg :selected-oper-pb)
    (selected-test-pb :cell :ephemeral :accessor selected-test-pb
		     :initform (c-in nil) :initarg :selected-test-pb))
   (:default-initargs
      :id :psu-rc-app-view
      :kids (c? (the-kids
		 (app-menubar)
		 (control-panel)
		 (darc-setup-panel)
		 ))))

;(defmethod initialize-instance :after ((self psu-rc-app-view) &key)
;  (tk-format '(:configure "title") "wm title . ~a" (slot-value self  
'title$)))

(defobserver title$ ((self window))
   (tk-format '(:configure "title") "wm title . ~a" (or new-value  
"Untitled")))

(defun app-menubar ()
   (mk-menubar
      :id :psu-rc-menu-bar
      :kids (c? (the-kids
		  (mk-menu-entry-cascade-ex (:label "File")
		     (mk-menu-entry-command
		        :label   "Quit"
		        :command "exit"))
		  (mk-menu-entry-cascade-ex (:label "Operate")
		     (mk-menu-entry-command
		        :label   "Set Mains Status to :OK"
			:command (c? (tk-callback .tkw 'set-mains-ok
						  (lambda () (setf (mains-status *psu-rc-app*) :ok)))))
		     (mk-menu-entry-command
		        :label "Action: Push the OPER MODE button"
                         :command (c? (tk-callback .tkw 'push-oper- 
mode-pb
				       (lambda ()
					 (setf (pressed (fm^ :oper-mode-pb)) t))))
		     )
		  )
		)
	   )
   )
)

(defun darc-setup-panel () ; <<< frgo: HERE

   (mk-stack ()
     (mk-row ()
       (mk-label :text "DARC RS232C Port Device Name:")
       (mk-entry :id :darc-port-device-name
		:md-value (c-in "")
		:background "grey"))
     (mk-row ()
       (mk-label :text "DARC Connect Status:")
       (mk-canvas ;;
          :height 40
	 :width  40
	 :kids (c? (the-kids (mk-rectangle
			        :coords '(0 0 40 40)
				:tk-fill (c? (if (eq (if (darc-rs232c-port *psu-rc-app*) (status  
(darc-rs232c-port *psu-rc-app*))
							 nil)
						     :connected)
						   "green"
						   "red")))))))
     (mk-row ()
       (mk-label :text (c? (if (darc-rs232c-port *psu-rc-app*)
			        (status (darc-rs232c-port *psu-rc-app*))
				""))
		:relief 'sunken))))

(defun run-psu-rc-app ()
   (cells-reset 'tk-user-queue-handler)
   (tk-test-class 'psu-rc-app))



From tfb at ocf.berkeley.edu  Thu Apr 13 21:15:39 2006
From: tfb at ocf.berkeley.edu (Thomas F. Burdick)
Date: Thu, 13 Apr 2006 23:15:39 +0200
Subject: [cells-devel] Celtk/cells: No Widgets! Help!
In-Reply-To: <7B19F8DF-9380-4354-86E1-4CC5DEC920E8@prion.de>
References: <7B19F8DF-9380-4354-86E1-4CC5DEC920E8@prion.de>
Message-ID: <b61efa90604131415i6b303707ya3568aa4b9dadafe@mail.gmail.com>

On 4/13/06, Frank Goenninger <fgoenninger at prion.de> wrote:
> Hi again ...
>
> With substantial help I was able to get some more stuff to work as
> expected. Now I am struggling with the fact that the menubar does
> indeed have the menus I installed but the few widgets I placed into
> the window simply don't appear...
>
> Hmm - well, yes, why?? (As always, there's a FRGO placed here and there)
>
> How do I debug what is being sent to wish ?

Ltk itself obeys a variable *debug-tk* which, when true, causes it to
echo everything to *standard-output*.  Since it looks like Kenny has
his own format-wish function, you'll need to edit those.

However, mysteriously missing widgets sounds like something isn't
being packed.  You may have a situation like:

  toplevel
    |
    +-frame
        |
        +widget
        +widget

Where you pack the two widgets, but not the frame.  Or, maybe you're
mixing grid and pack, which can be tricky.


From kentilton at gmail.com  Thu Apr 13 21:23:03 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Thu, 13 Apr 2006 17:23:03 -0400
Subject: [cells-devel] Celtk/cells: No Widgets! Help!
In-Reply-To: <7B19F8DF-9380-4354-86E1-4CC5DEC920E8@prion.de>
References: <7B19F8DF-9380-4354-86E1-4CC5DEC920E8@prion.de>
Message-ID: <a44bc6a10604131423u74bed28bi7bcd52cd00c4449c@mail.gmail.com>

Did you get the bit I sent to prion.de? I will resend to your mac account.

On 4/13/06, Frank Goenninger <fgoenninger at prion.de> wrote:
>
> Hi again ...
>
> With substantial help I was able to get some more stuff to work as
> expected. Now I am struggling with the fact that the menubar does
> indeed have the menus I installed but the few widgets I placed into
> the window simply don't appear...
>
> Hmm - well, yes, why?? (As always, there's a FRGO placed here and there)


Nothing inherits from any TK widget. I added ctk::button to
application-object and made other changes I noted in what I sent and could
see a panel. Actually I went back and exported button from Celtk, which was
just an oversight.

How do I debug what is being sent to wish ?


Hack ctk::tk-format-now in various ways to see all or selected messages.

Totally late, gotta run, but will resend shortly.

kt


Thx for any inputs.
>
> Frank
>
> ---
>
> ;; -*- mode: Lisp; Syntax: Common-Lisp; Package: celtk-user; -*-
>
> (in-package :cl-user)
>
> (eval-when (:load-toplevel :compile-toplevel :execute)
> #+asdf (progn
>      #-cells (asdf:operate 'asdf:load-op :cells)
>      #-Celtk (asdf:operate 'asdf:load-op :Celtk)
> ))
>
> (in-package :celtk-user)
>
> (defparameter *psu-rc-app* nil
>    "The instance of the PSU Remote Control application.")
>
> ;; BASE CLASS FOR APPLICATIONS
>
> (defmodel application ()
>    (( .md-value :cell t :accessor view   :initform (c-in
> nil)       :initarg :view )
>     ( name   :cell t :accessor name   :initform (c-in
> nil)       :initarg :name )
>     ( status :cell t :accessor status :initform (c-
> in :disabled) :initarg :status)
>    ))
>
> ;(defmethod initialize-instance :after ((self application) &key)
> ;  (incf (nr-instances self))) - does not work ...
>
> (defmodel application-object (family)
>    (( .md-name :cell t :accessor id :initform (c-
> in :unknown) :initarg :id )))
>
> ;; PUSHBUTTON, SIGNAL-LAMP, PUSHBUTTON-WITH-SIGNAL-LAMP MODELS
>
> (defmodel pushbutton (application-object)
>    (( .md-value :cell t
>                :accessor pb-state
>                :initform (c? (if (^pressed)
>                                    (on-off-toggle .cache)
>                                  (initial-pb-state self)))
>                :initarg :pb-state )
>     ( initial-pb-state :cell nil
>                       :initform :off
>                       :initarg :initial-pb-state
>                       :reader initial-pb-state )
>     ( pressed :cell :ephemeral
>              :accessor pressed
>              :initform (c-in nil))))
>
> (defmacro mk-pushbutton (&rest initargs)
>    `(make-instance 'pushbutton
>                   :fm-parent *parent*
>                   , at initargs))
>
> ;(defmacro push-the-button (button-id)
> ;  `(setf (fm^v ,button-id) :pressed))
>
> (defmodel signal-lamp (application-object)
>    ((lamp-state :cell t
>                :accessor lamp-state
>                :initform (c? (if (^switched)
>                                    (not .cache)
>                                  (initial-lamp-state self)))
>                :initarg :lamp-state )
>     ( initial-lamp-state :cell nil
>                         :initform :off
>                         :initarg :initial-lamp-state
>                         :reader initial-lamp-state )
>     ( switched :cell :ephemeral
>               :accessor switched
>               :initform (c-in nil))))
>
> (defmacro mk-signal-lamp (&rest initargs)
>    `(make-instance 'signal-lamp
>                   :fm-parent *parent*
>                   , at initargs))
>
> (defmodel pushbutton-with-signal-lamp (pushbutton signal-lamp)
>    ())
>
> (defmacro mk-pushbutton-with-signal-lamp (&rest initargs)
>    `(make-instance 'pushbutton-with-signal-lamp
>                   :fm-parent *parent*
>                   , at initargs))
>
> ;; PSU-APP-RC MODEL
>
> (defun control-panel ()
>    (list
>      ;; SIGNAL LAMPS
>
>      ;; Mains signal lamp
>      (mk-signal-lamp :id :mains-lamp
>                     ;:lamp-state (cr-mains-lamp-state)
>                     )
>
>      ;; OPER signal lamp
>      (mk-signal-lamp :id :oper-lamp
>                     ;:lamp-state (cr-oper-lamp-state)
>                     )
>
>      ;; TEST signal lamp
>      (mk-signal-lamp :id :test-lamp
>                     ;:lamp-state (cr-test-lamp-state)
>                     )
>
>      ;; FAIL signal lamp
>      (mk-signal-lamp :id :fail-lamp
>                     ;:lamp-state (cr-fail-lamp-state)
>                     )
>      ;; PUSH BUTTONS AND LAMPS
>
>      ;; Oper mode pushbutton with lamp
>      (mk-pushbutton-with-signal-lamp :id :oper-mode-pb
>                                     :initial-pb-state :off
>                                     :lamp-state (c? (if (^pressed)
>                                                           (^pb-state)
>                                                         (initial-lamp-state
> self)))
>                                     )
>
>      ;; Test mode pushbutton with lamp
>      (mk-pushbutton-with-signal-lamp :id :test-mode-pb
>                                     :initial-pb-state :off
>                                     ;:lamp-state (c? (^pb-state))
>                                     )
>
>      ;; Ua-enable pushbutton with lamp
>      (mk-pushbutton-with-signal-lamp :id :Ua-enable-pb
>                                     :initial-pb-state :off)
>
>      ;; Ug1 pushbutton with lamp
>      (mk-pushbutton-with-signal-lamp :id :Ug1-pb
>                                     :initial-pb-state :off)
>
>      ;; Ug2 pushbutton with lamp
>      (mk-pushbutton-with-signal-lamp :id :Ug2-pb
>                                     :initial-pb-state :off)
>
>      ;; Uh pushbutton with lamp
>      (mk-pushbutton-with-signal-lamp :id :Uh-pb
>                                     :initial-pb-state :off)
>
>      ;; Uh pushbutton with lamp
>      (mk-pushbutton-with-signal-lamp :id :Uh-pb
>                                     :initial-pb-state :off)
>    )
> )
>
> (defmodel psu-rc-app (application)
>    (
>      ;; Mains status (may have several vaklues, :ok indicates OK ;-)
>      ( mains-status :cell t :accessor mains-status :initform (c-in nil)
>                    :initarg :mains-status )
>
>      ;; Operate status: eitehr :operate-mode  or :test-mode
>      ( operate-status :cell t :accessor operate-status :initform (c-
> in nil)
>                      :initarg :operate-status )
>
>      ;; RS232C port
>      ;; As soon as the port name is set try to read data from this port
>      ;; DARC stands for Device and Application Remote Control
>      ( darc-rs232c-port :cell t :accessor darc-rs232c-port
>                        :initform (c-in nil)
>                        :initarg :darc-rs232c-port )
>
>      ;; Voltage and current values to be
> displayed                      Units
>      ( Ua  :cell t :accessor Ua  :initform (c-in
> nil) :initarg :Ua )  ; [ V ]
>      ( Ia  :cell t :accessor Ia  :initform (c-in
> nil) :initarg :Ia )  ; [ A ]
>      ( Uh  :cell t :accessor Uh  :initform (c-in
> nil) :initarg :Uh )  ; [ V ]
>      ( Ih  :cell t :accessor Ih  :initform (c-in
> nil) :initarg :Ih )  ; [ A ]
>      ( Ug1 :cell t :accessor Ug1 :initform (c-in
> nil) :initarg :Ug1 ) ; [ V ]
>      ( Ig1 :cell t :accessor Ig1 :initform (c-in
> nil) :initarg :Ig1 ) ; [ mA ]
>      ( Ug2 :cell t :accessor Ug2 :initform (c-in
> nil) :initarg :Ug2 ) ; [ V ]
>      ( Ig2 :cell t :accessor Ig2 :initform (c-in
> nil) :initarg :Ig2 ) ; [ mA ]
>    )
> )
>
> (defmodel rs232c-port (window) ; needs to be a widget to get a
>                                 ; timer easily ;-)
>    (( status :accessor status
>             :cell t
>             :initform (c-in :not-connected))
>     ( device-name :accessor device-name
>                  :cell t
>                  :initform (c-in nil)
>                  :initarg :device-name ))
>    (:default-initargs
>       :id :darc-port
>       :timers (c? (list
>                    (make-instance 'timer
>                                   :state (c-in :off)
>                                   :repeat t
>                                   :delay 10000 ; 10 s delay
>                                   :action (lambda (timer)
>                                              (declare (ignore timer))
>                                              (let ((status (status
> (darc-rs232c-port *psu-rc-app*)))
>                                                    (device-name
> (device-name (darc-rs232c-port *psu-rc-app*))))
>                                              (if (and (eq status
>                                                           :not-connected)
>                                                       device-name )
>                                                (connect-to-darc
> device-name)))))))))
>
> (defun connect-to-darc (device-name)
>
>    (format t "~%*** connect-to-darc been called for port ~a ...~&"
> device-name)
>
>    (when device-name
>      (format t "~%*** Trying to connect to DARC via port ~a ...~&"
> device-name)
>
>      ;; Missing: Code that connects to the DARC port via USB ...
>      ;; For now, just return NOT CONNECTED ...
>
>      :not-connected
>      )
> )
>
> (defobserver status ((self rs232c-port))
>    (format t "~%*** Status of RS232C port ~a is now ~s.~%"
>             (device-name self)
>             (status self))
>    (when new-value
>      (if (eq new-value :connected)
>           (setf (state (first (timers self))) :off)
>          (setf (state (first (timers self))) :on)
>         )))
>
> ;; HELPER FUNCTIONS
>
> ;; Toggles :on to :off and vice versa
> (defun on-off-toggle (on-or-off)
>    (case on-or-off
>      ( :on  :off)
>      ( :off :on )
>      (otherwise :off))) ; Safety ! Turn off in case of unknown value
> given
>                         ; (= bug in app) ...
>
> ;; PSU-RC-APP OBSERVERS
>
> (defobserver mains-status ((self psu-rc-app))
>    (format t "~%*** Mains-status is now ~s.~%" new-value))
>
> (defobserver lamp-state ((self signal-lamp))
>    (format t "~%*** Signal lamp ~a is now ~s.~%" (id self) new-value))
>
> (defobserver pressed ((self pushbutton))
>    (format t "~%*** Pushbutton ~a has been pressed (~s).~%" (id self)
> new-value))
>
> (defobserver switched ((self signal-lamp))
>    (format t "~%*** Lamp ~a has been switched (~s).~%" (id self) new-
> value))
>
> ;(defobserver pressed ((self pushbutton-with-signal-lamp))
> ;  (setf (switched (fm^ (md-name self)) t)))
>
> ;; Get a view / window right after making an instance
> ;; We only allow one instance to run !
>
> (defmethod initialize-instance :after ((self psu-rc-app) &key)
>    (when *psu-rc-app*
>      (error "*** A PSU-APP-RC instance already exists. Only one
> allowed."))
>    (setq *psu-rc-app* self)
>    (setf (view self) (make-instance 'psu-rc-app-view))
>    (setf (darc-rs232c-port self) (make-instance 'rs232c-port)))
>
> ;; PSU-RC-APP-VIEW - the view/GUI for the PSU Remote Control Application
>
> (defmodel psu-rc-app-view (window)
>    ((selected-oper-pb :cell :ephemeral :accessor selected-oper-pb
>                      :initform (c-in nil) :initarg :selected-oper-pb)
>     (selected-test-pb :cell :ephemeral :accessor selected-test-pb
>                      :initform (c-in nil) :initarg :selected-test-pb))
>    (:default-initargs
>       :id :psu-rc-app-view
>       :kids (c? (the-kids
>                  (app-menubar)
>                  (control-panel)
>                  (darc-setup-panel)
>                  ))))
>
> ;(defmethod initialize-instance :after ((self psu-rc-app-view) &key)
> ;  (tk-format '(:configure "title") "wm title . ~a" (slot-value self
> 'title$)))
>
> (defobserver title$ ((self window))
>    (tk-format '(:configure "title") "wm title . ~a" (or new-value
> "Untitled")))
>
> (defun app-menubar ()
>    (mk-menubar
>       :id :psu-rc-menu-bar
>       :kids (c? (the-kids
>                   (mk-menu-entry-cascade-ex (:label "File")
>                      (mk-menu-entry-command
>                         :label   "Quit"
>                         :command "exit"))
>                   (mk-menu-entry-cascade-ex (:label "Operate")
>                      (mk-menu-entry-command
>                         :label   "Set Mains Status to :OK"
>                         :command (c? (tk-callback .tkw 'set-mains-ok
>                                                   (lambda () (setf
> (mains-status *psu-rc-app*) :ok)))))
>                      (mk-menu-entry-command
>                         :label "Action: Push the OPER MODE button"
>                          :command (c? (tk-callback .tkw 'push-oper-
> mode-pb
>                                        (lambda ()
>                                          (setf (pressed (fm^
> :oper-mode-pb)) t))))
>                      )
>                   )
>                 )
>            )
>    )
> )
>
> (defun darc-setup-panel () ; <<< frgo: HERE
>
>    (mk-stack ()
>      (mk-row ()
>        (mk-label :text "DARC RS232C Port Device Name:")
>        (mk-entry :id :darc-port-device-name
>                 :md-value (c-in "")
>                 :background "grey"))
>      (mk-row ()
>        (mk-label :text "DARC Connect Status:")
>        (mk-canvas ;;
>           :height 40
>          :width  40
>          :kids (c? (the-kids (mk-rectangle
>                                 :coords '(0 0 40 40)
>                                 :tk-fill (c? (if (eq (if (darc-rs232c-port
> *psu-rc-app*) (status
> (darc-rs232c-port *psu-rc-app*))
>                                                          nil)
>                                                      :connected)
>                                                    "green"
>                                                    "red")))))))
>      (mk-row ()
>        (mk-label :text (c? (if (darc-rs232c-port *psu-rc-app*)
>                                 (status (darc-rs232c-port *psu-rc-app*))
>                                 ""))
>                 :relief 'sunken))))
>
> (defun run-psu-rc-app ()
>    (cells-reset 'tk-user-queue-handler)
>    (tk-test-class 'psu-rc-app))
>
> _______________________________________________
> cells-devel site list
> cells-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060413/be5870ee/attachment.html>

From kentilton at gmail.com  Fri Apr 14 03:20:58 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Thu, 13 Apr 2006 23:20:58 -0400
Subject: [cells-devel] Celtk/cells: No Widgets! Help!
In-Reply-To: <b61efa90604131415i6b303707ya3568aa4b9dadafe@mail.gmail.com>
References: <7B19F8DF-9380-4354-86E1-4CC5DEC920E8@prion.de>
	<b61efa90604131415i6b303707ya3568aa4b9dadafe@mail.gmail.com>
Message-ID: <443F151A.8080809@gmail.com>

Thomas F. Burdick wrote:

>On 4/13/06, Frank Goenninger <fgoenninger at prion.de> wrote:
>  
>
>>Hi again ...
>>
>>With substantial help I was able to get some more stuff to work as
>>expected. Now I am struggling with the fact that the menubar does
>>indeed have the menus I installed but the few widgets I placed into
>>the window simply don't appear...
>>
>>Hmm - well, yes, why?? (As always, there's a FRGO placed here and there)
>>
>>How do I debug what is being sent to wish ?
>>    
>>
>
>Ltk itself obeys a variable *debug-tk* which, when true, causes it to
>echo everything to *standard-output*.  Since it looks like Kenny has
>his own format-wish function, you'll need to edit those.
>
>  
>
Yep. Somewhat condensed:

(defun tk-format-now (fmt$ &rest fmt-args &aux (tk$ (apply 'format nil 
fmt$ fmt-args)))
  (let ((yes '("font"))
        (no  '()))
    (when (and (find-if (lambda (s) (search s tk$)) yes)
            (not (find-if (lambda (s) (search s tk$)) no)))
      (format t "~&tk> ~a~%" tk$)))
 
  (assert (wish-stream *wish*)) ;; when not??
  (setf *tk-last* tk$)
  (format (wish-stream *wish*) "~a~%" tk$)
  (force-output (wish-stream *wish*)))

Hack that to get various amounts of output.

>However, mysteriously missing widgets sounds like something isn't
>being packed.  You may have a situation like:
>
>  toplevel
>    |
>    +-frame
>        |
>        +widget
>        +widget
>
In this case we had both a failure to inherit from widgets as well as a 
failure to pack the toplevel widgets, understandable given the utter 
documentation void. :)

kt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060413/23677f42/attachment.vcf>

From fgoenninger at prion.de  Fri Apr 14 13:47:40 2006
From: fgoenninger at prion.de (Frank Goenninger)
Date: Fri, 14 Apr 2006 15:47:40 +0200
Subject: [cells-devel] Celtk/cells: No Widgets! Help!
In-Reply-To: <443F151A.8080809@gmail.com>
References: <7B19F8DF-9380-4354-86E1-4CC5DEC920E8@prion.de>
	<b61efa90604131415i6b303707ya3568aa4b9dadafe@mail.gmail.com>
	<443F151A.8080809@gmail.com>
Message-ID: <843FE4D1-5720-42AD-963F-E4D51061B1E2@prion.de>

Hi all:

Thanks for all the feedback. I had various problems with my Apple  
Mail.app on the still a bit rough MacBook Pro on Intel... I apologize  
for sending some of my requests in  multiple ways ...

Anyway:

Am 14.04.2006 um 05:20 schrieb Ken Tilton:

> Thomas F. Burdick wrote:
>
>> On 4/13/06, Frank Goenninger <fgoenninger at prion.de> wrote:
>>
>>> Hi again ...
>>>
>>> With substantial help I was able to get some more stuff to work as
>>> expected. Now I am struggling with the fact that the menubar does
>>> indeed have the menus I installed but the few widgets I placed into
>>> the window simply don't appear...
>>>
>>> Hmm - well, yes, why?? (As always, there's a FRGO placed here and  
>>> there)
>>>
>>> How do I debug what is being sent to wish ?
>>>
>>
>> Ltk itself obeys a variable *debug-tk* which, when true, causes it to
>> echo everything to *standard-output*.  Since it looks like Kenny has
>> his own format-wish function, you'll need to edit those.
>>
>>
> Yep. Somewhat condensed:
>
> (defun tk-format-now (fmt$ &rest fmt-args &aux (tk$ (apply 'format  
> nil fmt$ fmt-args)))
>  (let ((yes '("font"))
>        (no  '()))
>    (when (and (find-if (lambda (s) (search s tk$)) yes)
>            (not (find-if (lambda (s) (search s tk$)) no)))
>      (format t "~&tk> ~a~%" tk$)))
>  (assert (wish-stream *wish*)) ;; when not??
>  (setf *tk-last* tk$)
>  (format (wish-stream *wish*) "~a~%" tk$)
>  (force-output (wish-stream *wish*)))
>
> Hack that to get various amounts of output.

Will do.

>
>> However, mysteriously missing widgets sounds like something isn't
>> being packed.  You may have a situation like:
>>
>>  toplevel
>>    |
>>    +-frame
>>        |
>>        +widget
>>        +widget
>>
> In this case we had both a failure to inherit from widgets as well  
> as a failure to pack the toplevel widgets, understandable given the  
> utter documentation void. :)

Well, in my case add to this the simple fact I've never done Tk  
before...

As always: Great help from you guys! Thx!

Now back to hacking...

Happy Easter!

Frank



From fgoenninger at prion.de  Fri Apr 14 14:11:58 2006
From: fgoenninger at prion.de (Frank Goenninger)
Date: Fri, 14 Apr 2006 16:11:58 +0200
Subject: [cells-devel] Re: Celtk/cells: timing issue in initialization and
	No Widgets :-(
In-Reply-To: <443EA0C0.7080207@gmail.com>
References: <63A8B78A-7D99-4E99-AD3C-212970B54BFE@prion.de>
	<443EA0C0.7080207@gmail.com>
Message-ID: <3BAA9F9E-4A94-4487-8E91-41EA7957F4B9@prion.de>

Am 13.04.2006 um 21:04 schrieb Ken Tilton:

> Frank,
>
> I see a few things. Deets next, but first my inclination is to  
> leave the problems in place and work on the core to provide helpful  
> error messages where possible (I will do anything to avoid writing  
> documentation <g>). This will have the advantage over documentation  
> in that it will catch careless veteran mistakes as well as newby  
> mistakes.

Understood.

>
> Issues:
>
> 1. darc-setup-panel begins:
>
> (defun darc-setup-panel ()
>    (mk-stack ()
>       <list of widgets>))
>
> That is good in one respect, contrasted with control-panel, which  
> begins
>
> (defun control-panel ()
>   (list
>      <list-of-widgets>))
>
> That is not absolutely the end of the world, because the-kids here:
>
> (defmodel psu-rc-app-view (window)
>  ((selected-oper-pb :cell :ephemeral :accessor selected-oper-pb
>     :initform (c-in nil) :initarg :selected-oper-pb)
>   (selected-test-pb :cell :ephemeral :accessor selected-test-pb
>     :initform (c-in nil) :initarg :selected-test-pb))
>  (:default-initargs
>      :id :psu-rc-app-view
>    :kids (c? (the-kids
>               (app-menubar)
>               (control-panel)
>               (darc-setup-panel)
>               ))))
>
> Will flatten out the list returned by control-panel. In the end,  
> every component listed by control-panel becomes a top-level widget  
> of the window, meaning it needs packing instructions. And this  
> brings us to the problem with the darc-setup-panel: it needs  
> packing, too.
>
> If you use stacks and rows, their kids get default packing. But the  
> toplevel widget in a window does not get default packing. I tried  
> that, but it gets in the way of the parent trying to do packing if  
> the kids are doing packing. To do custom packing, one first must  
> specify nil values for kid-packing values, then one has to pack  
> each kid manually. I would explain that more, but let's just use  
> stacks and rows.
>
> I do not know how you visualize the outcome, but I see two big  
> stacks coming, so:
>
> control-panel now starts:
>     (mk-stack ()
>         <widgets>)
>
> and psu-rc-app-view kids becomes:
>    (the-kids
>        (app-menubar)
>        (mk-row (:packing (c?pack-self)) ;; accept all TK  packing  
> defaults
>            (control-panel)

No. Control Panel is currently just the model. No View yet.

>            (darc-setup-panel))))

This is a View with an integrated model. No really pure OO just a  
quick hack.

I see I should do a widget hierarchy that looks like

window
       |
      +--- frame (= darc-setup-panel-frame)
      |          |
      |          |--- row
      |                    |--- ...
      |
      ----- frame (= control-panel-frame)
                |
                |---- row
                         |--- ....  Here the yet not coded control  
panel widgets should go in.

>
> btw, if you check the lotsa-widgets demo you will see it starts  
> that way. My policy when working with hairy libraries (like Celtk,  
> I admit) is to take some sample code, make sure it works, and then  
> rename it "kennys-new-app" and change things only as I need to.  
> That let's me avoid /reading/ doc. (Notice a trend?) Eventually all  
> the original code is gone and I understand what remains. Anyway...
>
> With the above changes I now get a complaint about signal-lamp not  
> having a path method, and I see that that is an "application- 
> object", which suggests to me that you do not want it in the GUI at  
> all, that all those are part of the model. I think we are on the  
> verge of some deep OO design issues here. :)

Yep. As I admitted: Just a quick hack so far to test out several things.

> Let me send this off and stare at the code some more.
>
> kt

Now let me code some more to come up with a  clean Model/View  
separation  and with your inputs included.

THX!

Frank



From kentilton at gmail.com  Fri Apr 14 15:50:50 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Fri, 14 Apr 2006 11:50:50 -0400
Subject: [cells-devel] Re: Celtk/cells: timing issue in initialization and
	No Widgets :-(
In-Reply-To: <3BAA9F9E-4A94-4487-8E91-41EA7957F4B9@prion.de>
References: <63A8B78A-7D99-4E99-AD3C-212970B54BFE@prion.de>
	<443EA0C0.7080207@gmail.com>
	<3BAA9F9E-4A94-4487-8E91-41EA7957F4B9@prion.de>
Message-ID: <443FC4DA.6050401@gmail.com>

Frank Goenninger wrote:

>
> No. Control Panel is currently just the model. No View yet.

OK. Well, I guess there is no problem having non-GUI model (vs view, 
that is) instance as kids of the Window. If they are not subclasses of 
TK widgets, they will just sit there but still be in the fm-find*-able 
namespace, which is probably a good thing. Note tho that you could just 
stick them someplace else and still use the fm-find* routines by 
providing that someplace else as an argument to the fm-find stuff.

>
>>            (darc-setup-panel))))
>
>
> This is a View with an integrated model. No really pure OO just a  
> quick hack.
>
> I see I should do a widget hierarchy that looks like
>
> window
>       |
>      +--- frame (= darc-setup-panel-frame)
>      |          |
>      |          |--- row
>      |                    |--- ...
>      |
>      ----- frame (= control-panel-frame)
>                |
>                |---- row
>                         |--- ....  Here the yet not coded control  
> panel widgets should go in.
>
OK, just remember to specify the :packing argument (or get fancy and try 
grid or place, but I do not think I have any support yet for place) for 
the toplevel frames.

kt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060414/66488e8c/attachment.vcf>

From fgoenninger at prion.de  Fri Apr 14 19:30:46 2006
From: fgoenninger at prion.de (Frank Goenninger)
Date: Fri, 14 Apr 2006 21:30:46 +0200
Subject: [cells-devel] Re: Celtk/cells: timing issue in initialization and
	No Widgets :-(
In-Reply-To: <443FC4DA.6050401@gmail.com>
References: <63A8B78A-7D99-4E99-AD3C-212970B54BFE@prion.de>
	<443EA0C0.7080207@gmail.com>
	<3BAA9F9E-4A94-4487-8E91-41EA7957F4B9@prion.de>
	<443FC4DA.6050401@gmail.com>
Message-ID: <95B67DB6-C476-4A0C-98A3-FB432485B41B@prion.de>


Am 14.04.2006 um 17:50 schrieb Ken Tilton:

> Frank Goenninger wrote:
>
>>
>> No. Control Panel is currently just the model. No View yet.
>
> OK. Well, I guess there is no problem having non-GUI model (vs  
> view, that is) instance as kids of the Window. If they are not  
> subclasses of TK widgets, they will just sit there but still be in  
> the fm-find*-able namespace, which is probably a good thing. Note  
> tho that you could just stick them someplace else and still use the  
> fm-find* routines by providing that someplace else as an argument  
> to the fm-find stuff.
>
>>
>>>            (darc-setup-panel))))
>>
>>
>> This is a View with an integrated model. No really pure OO just a   
>> quick hack.
>>
>> I see I should do a widget hierarchy that looks like
>>
>> window
>>       |
>>      +--- frame (= darc-setup-panel-frame)
>>      |          |
>>      |          |--- row
>>      |                    |--- ...
>>      |
>>      ----- frame (= control-panel-frame)
>>                |
>>                |---- row
>>                         |--- ....  Here the yet not coded control   
>> panel widgets should go in.
>>
> OK, just remember to specify the :packing argument (or get fancy  
> and try grid or place, but I do not think I have any support yet  
> for place) for the toplevel frames.
>
> kt

I remembered. And did it. Now the widgets appear. Yeah!

Now back to the initialization timing condition stuff...

Frank



From fgoenninger at prion.de  Thu Apr 20 14:42:04 2006
From: fgoenninger at prion.de (Frank Goenninger)
Date: Thu, 20 Apr 2006 16:42:04 +0200
Subject: [cells-devel] Celtk/Cells: How to best do own new widgets...
Message-ID: <9F7D9D7F-F54D-42F4-8620-E0B4400164B4@prion.de>

Kenny, all:

some status report on my endeavor to create a hobby app with Celtk  
and also a few things to discuss:

I have put together the GUI prototype for my app - using Tcl/Tk  
directly. Purpose was to learn Tcl/Tk and see how well I could do  
some advanced things like building my own widgets / GUI elements  
using only basic commands as supported by Celtk.

Now there's some GUI there that can be translated straightforward to  
Celtk  except for a meter widget for displaying analog value like  
voltage and current. You can test the GUI by firing it up with

wish psu-rc-gui.tcl

using the attached files. One is a font file that is needed to  
display LCD type characters (font DS-Dgital, folder ds-digital).

I used the voltmeter.tcl file by Marco Maggi  (http://wiki.tcl.tk/ 
9109) as a reference but decided to go without actually creating a Tk  
widget.

Now, I see the that I'd like to use some kind of new widget class  
either by sub-classing Celtk:widget or by enhancing the Celtk:widget  
class. I'd need some possibility to send over Tcl/Tk code to the wish  
upon first instance creation in order to install the widget on the Tk  
side. That's approach #1.

#2 would be to do this all in Lisp and just send the drawing commands  
to the wish...

Hmmm!? Which one would you choose. Why ?

Thanks for any feedback!

Cheers
    Frank


P.S. If there's no files attached I think the cells-devel list does  
not allow posting attachments ... I'll send you the files if you say so.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: psu-rc-gui.tcl
Type: application/octet-stream
Size: 24030 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060420/45613930/attachment.obj>
-------------- next part --------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ds_digital.zip
Type: application/zip
Size: 37548 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060420/45613930/attachment.zip>

From kentilton at gmail.com  Thu Apr 20 16:29:38 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Thu, 20 Apr 2006 12:29:38 -0400
Subject: [cells-devel] Celtk/Cells: How to best do own new widgets...
In-Reply-To: <9F7D9D7F-F54D-42F4-8620-E0B4400164B4@prion.de>
References: <9F7D9D7F-F54D-42F4-8620-E0B4400164B4@prion.de>
Message-ID: <4447B6F2.8020006@gmail.com>

Frank Goenninger wrote:

> Kenny, all:
>
> some status report on my endeavor to create a hobby app with Celtk  
> and also a few things to discuss:
>
> I have put together the GUI prototype for my app - using Tcl/Tk  directly.

Very nice!

> Purpose was to learn Tcl/Tk and see how well I could do  some advanced 
> things like building my own widgets / GUI elements  using only basic 
> commands as supported by Celtk.
>
> Now there's some GUI there that can be translated straightforward to  
> Celtk  except for a meter widget for displaying analog value like  
> voltage and current. 

I did not see anything (in a quick scan) that Celtk could not handle. 
Straightforward? Well, there is a /lot/ of code. :) And I think some of 
the code I saw begs for me to port more of my typical positioning logic 
to Celtk. These would replace Tk positioning productivity tricks pack 
and grid and rely on place (and parent-relative canvas coord scheme). 
Some of this has already been done for my commercial app.

> You can test the GUI by firing it up with
>
> wish psu-rc-gui.tcl

heh-heh. I double-clicked the file in my FireFox downloads list and up 
it came! had to get fancy to see the text. :)

>
> using the attached files. One is a font file that is needed to  
> display LCD type characters (font DS-Dgital, folder ds-digital).
>
> I used the voltmeter.tcl file by Marco Maggi  (http://wiki.tcl.tk/ 
> 9109) as a reference but decided to go without actually creating a Tk  
> widget.
>
> Now, I see the that I'd like to use some kind of new widget class  
> either by sub-classing Celtk:widget or by enhancing the Celtk:widget  
> class. I'd need some possibility to send over Tcl/Tk code to the wish  
> upon first instance creation in order to install the widget on the Tk  
> side. That's approach #1.
>
> #2 would be to do this all in Lisp and just send the drawing commands  
> to the wish...
>
> Hmmm!? Which one would you choose. Why ?

Do it all in Lisp. Why? Mainly because, looking at your code, Tk is not 
buying you anything over Celtk. all the calculations you do could be 
done as easily in Lisp. And then when you get beyond the GUI, Tk 
/really/ does not add value. I definitely want to write the hard part 
(there may not be a "hard part" to this controller, but as a rule...) in 
Lisp. So if my GUI is in Lisp and my model is in Lisp, they can easily 
talk to each other. People talk about separation of model and view, but 
they /do/ have to talk to each other, and when it is easy, developers 
tend to go further with GUIs than when it is painful. "Sure, gimme an 
hour then come back to test it" So I would as a rule rather be writing 
Lisp.

Almost as important, I think you would like the way it all turns out 
with Cells. Mind you, if your Tcl were stronger I think this would have 
been easier. I am looking at the way you positioned one button to the 
right of another by hardcoding an offset off the prior buttons position:

> set oper_lamp_x $hv_enable_lamp_x
> signal_lamp $oper_lamp_x $lamps1_y $lamps1_w $lamps1_h green 
> .oper_mode_lamp
>
> set oper_text_x $hv_enable_x
> .c create text $oper_text_x $status_text_y -text "OPER" -anchor center \
>    -font status_text_font
>
> set test_lamp_x [ expr { $oper_lamp_x + $button_distance } ]
> signal_lamp $test_lamp_x $lamps1_y $lamps1_w $lamps1_h gold  
> .test_mode_lamp
>
If you do that in a loop over  a vector of button specs, the spacing can 
be calculated relatively. then you could change the order of buttons 
without re-hardwiring all the depenedencies.

If you got stuck on Celtk, I suggest you narrow this example down to a 
few buttons, a voltage meter and a few decorations and maybe I can toss 
something off in a couple of hours to get you jumpstarted. Maybe check 
with me on what to leave in/take out before actually hacking the code to 
make sure we agree on the scope I will be able to make time for.

cheers, ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060420/c135dd2f/attachment.vcf>

From fgoenninger at prion.de  Thu Apr 20 16:59:15 2006
From: fgoenninger at prion.de (Frank Goenninger)
Date: Thu, 20 Apr 2006 18:59:15 +0200
Subject: [cells-devel] Celtk/Cells: How to best do own new widgets...
In-Reply-To: <4447B6F2.8020006@gmail.com>
References: <9F7D9D7F-F54D-42F4-8620-E0B4400164B4@prion.de>
	<4447B6F2.8020006@gmail.com>
Message-ID: <93D4A2CD-0C51-4960-A3E8-AEA614F33C43@prion.de>


Am 20.04.2006 um 18:29 schrieb Ken Tilton:

> Frank Goenninger wrote:
>
>> Kenny, all:
>>
>> some status report on my endeavor to create a hobby app with  
>> Celtk  and also a few things to discuss:
>>
>> I have put together the GUI prototype for my app - using Tcl/Tk   
>> directly.
>
> Very nice!

Thanks ;-)

>> Purpose was to learn Tcl/Tk and see how well I could do  some  
>> advanced things like building my own widgets / GUI elements  using  
>> only basic commands as supported by Celtk.
>>
>> Now there's some GUI there that can be translated straightforward  
>> to  Celtk  except for a meter widget for displaying analog value  
>> like  voltage and current.
>
> I did not see anything (in a quick scan) that Celtk could not  
> handle. Straightforward? Well, there is a /lot/ of code. :) And I  
> think some of the code I saw begs for me to port more of my typical  
> positioning logic to Celtk. These would replace Tk positioning  
> productivity tricks pack and grid and rely on place (and parent- 
> relative canvas coord scheme).

Definitely something very useful to have, yes.

[snip]
>> Now, I see the that I'd like to use some kind of new widget class   
>> either by sub-classing Celtk:widget or by enhancing the  
>> Celtk:widget  class. I'd need some possibility to send over Tcl/Tk  
>> code to the wish  upon first instance creation in order to install  
>> the widget on the Tk  side. That's approach #1.
>>
>> #2 would be to do this all in Lisp and just send the drawing  
>> commands  to the wish...
>>
>> Hmmm!? Which one would you choose. Why ?
>
> Do it all in Lisp.

I knew it! ;-)

> Why? Mainly because, looking at your code, Tk is not buying you  
> anything over Celtk.

Yes, but:

If I create a widget class in Lisp that in effect has some GUI-only  
code (no controller, no model) in Tcl/Tk then all the drawing staff  
would be on the Tk side. That code would be sent once to the Wish  
when the first instance of that class is created.

This gives me the advantage of not sending always the whole drawing  
primitives over to Wisk. Instead I'd be able to call the widget's  
methods for updating as as single command with a few parameters.

> all the calculations you do could be done as easily in Lisp.

Yep. Of course. I'd do these always in Lisp, of course.

> And then when you get beyond the GUI, Tk /really/ does not add  
> value. I definitely want to write the hard part (there may not be a  
> "hard part" to this controller, but as a rule...) in Lisp. So if my  
> GUI is in Lisp and my model is in Lisp, they can easily talk to  
> each other. People talk about separation of model and view, but  
> they /do/ have to talk to each other, and when it is easy,  
> developers tend to go further with GUIs than when it is painful.  
> "Sure, gimme an hour then come back to test it" So I would as a  
> rule rather be writing Lisp.

That still would be the case in the Tk widget scenario provided that  
a single widget stays as it is and the GUI change is by re-arranging  
stuff layout-wise and/or adding/replacing widgets.

> Almost as important, I think you would like the way it all turns  
> out with Cells. Mind you, if your Tcl were stronger I think this  
> would have been easier. I am looking at the way you positioned one  
> button to the right of another by hardcoding an offset off the  
> prior buttons position:
>
>> set oper_lamp_x $hv_enable_lamp_x
>> signal_lamp $oper_lamp_x $lamps1_y $lamps1_w $lamps1_h  
>> green .oper_mode_lamp
>>
>> set oper_text_x $hv_enable_x
>> .c create text $oper_text_x $status_text_y -text "OPER" -anchor  
>> center \
>>    -font status_text_font
>>
>> set test_lamp_x [ expr { $oper_lamp_x + $button_distance } ]
>> signal_lamp $test_lamp_x $lamps1_y $lamps1_w $lamps1_h  
>> gold  .test_mode_lamp
>>
> If you do that in a loop over  a vector of button specs, the  
> spacing can be calculated relatively. then you could change the  
> order of buttons without re-hardwiring all the depenedencies.

I absolutely agree. To point this out: I'd not do this stuff in Tk. I  
*only* would do the analog meter as a widget in Tk.

> If you got stuck on Celtk, I suggest you narrow this example down  
> to a few buttons, a voltage meter and a few decorations and maybe I  
> can toss something off in a couple of hours to get you jumpstarted.  
> Maybe check with me on what to leave in/take out before actually  
> hacking the code to make sure we agree on the scope I will be able  
> to make time for.

Well, I'll for sure come back to you on this - thanks for offering  
your support! But why give up the fun part ? <g> OTOH I could use  
some help with AVR microcontroller assembler programming it being the  
main controller for the electrical hardware... You jumping in? ;-)

> cheers, ken
> <kentilton.vcf>

Thanks for the analysis! Already on the Celtk side now with my brand  
new Intel OS X ACL8.0 running on blazingly fast on my MacBook Pro ...

Frank



From kentilton at gmail.com  Thu Apr 20 20:40:01 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Thu, 20 Apr 2006 16:40:01 -0400
Subject: [cells-devel] Re: [Lisp] Rapid prototyping idea rewards crap
	(README)
In-Reply-To: <8353BBC285D8C14EA9259A5E5506F7F601261FDE@porthos.ny.rga.com>
References: <8353BBC285D8C14EA9259A5E5506F7F601261FDE@porthos.ny.rga.com>
Message-ID: <a44bc6a10604201340w48fa687byd3c630c11207f355@mail.gmail.com>

On 4/20/06, Jason Scherer <jason.scherer at rga.com> wrote:
>
>
> I wonder, is it legal to have one umbrella project and then have
> multiple students work on different pieces of that project?


Not last year. I have not looked at the rules this year. kt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060420/c86d116f/attachment.html>

From kentilton at gmail.com  Thu Apr 20 20:48:49 2006
From: kentilton at gmail.com (Ken Tilton)
Date: Thu, 20 Apr 2006 16:48:49 -0400
Subject: [cells-devel] Re: [Lisp] Rapid prototyping idea rewards crap
	(README)
In-Reply-To: <1145554841.1550.917.camel@sushi>
References: <a44bc6a10604191419x52155d5fx3a8f74309dbb9b78@mail.gmail.com>
	<1145502103.1546.801.camel@sushi>
	<a44bc6a10604200540y64d5f80bg9f28b1447322842a@mail.gmail.com>
	<1145554841.1550.917.camel@sushi>
Message-ID: <a44bc6a10604201348x42d451abndb409ec749d03d7@mail.gmail.com>

On 20 Apr 2006 13:40:40 -0400, Heow Eide-Goodman <lists at alphageeksinc.com>
wrote:
>
> Actually Kenny, you hit it on the nose.
>
> Here is the process as-envisioned:
>
>   1. A prospective student has a gread project idea
>   2. LispNYC reviews student and idea
>   3. If we determine that idea and student are considered worthy, then
> LispNYC says yeah or nay.
>   4. (if (eq 'nay (lisp-nyc-review-process student) 'adios) (progn ...
> ))
>   5. We think they've got a fighting chance then LispNYC pledges $500
>   6. Student works and works and works
>   7. Google reviews everything and the grants are awarded.
>   8. If they're not funded by Google, then we give them the $500
>
>
> Since our intent is to attract smart motivated students to get a
> head-start on the work rather than motivated shysters, then we should
> carefully consider this.  Everything comes with risks and this needs to
> mitigate our risk rather than increase it.
>
> Please consider this, carefully.
>
> The RCP process is exactly the same review that we use for Google.
> However, for a mere $500, it allows us:
>
>   * More time to scrutinize the student.
>   * Determine whether she is sufficiently motivated to complete the
> project.
>   * Better determine their technical chops, in Lisp or otherwise.


OK, this makes no sense. Why not let Google waste their $500 instead of
ours? We do the same due diligence either way, but if it turns out we
screwed up, we take the hit. And I  have to ask: what problem are you trying
to solve? We did great last year. There was one screw-up, and I am
completely to blame because I had an early warning of exactly what
transpired. We have learned that lesson and will be more careful this time
in the review process. But to be honest, again, I had all the early warning
in the world on the cl-sockets didaster, I just sailed through that flashing
red light.

I thought the angle was "attract more projects". That was at least
plausible. But, again, I doubt the guarantee would do that, I think it would
attract (not reward) more crap.

kt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060420/3ae0a07e/attachment.html>