[cells-devel] Celtk/Cells: How to best do own new widgets...

[Frank Goenninger]

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