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.
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
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
-
Frank Goenninger -
Ken Tilton