Updated 2012-09-19 09:32:15 by LkpPo ▲

Available at http://www.tcl.tk/starkits/gbutton.kit is a package that provides fancy graphical buttons for Tk. Why gbutton? Well, the package needed a prefix to distinguish it from the button widget. And g for graphical seemed obvious. Jeff Hobbs [1] did suggest "goober", but this has multiple meanings (all of them vaguely applicable).

Included are default images providing "jelly buttons" - but the developer can specify any images for the normal, depressed (sigh :-)) and disabled button states.

The package is distributed as a Starkit containing both the source and documentation (in the form of an internal read-only Wiki) - so for more information download the above link and run without arguments (using Tclkit).

LV 2007-01-01 Anyone know why I see this?
 $ chmod 755 /var/tmp/gbuttons.kit
 $  /var/tmp/gbutton.kit
 body object for proc attached to frame is not a byte code type
 Abort

Some people have asked "why Incr Tcl?". The answer is quite simple - when building event driven GUI code, an OO system avoids the need to carry around a lot of context, or polluting the global namespace. Any OO system would have done, but Incr Tcl is there, relatively stable and only around 50Kb per platform (when compressed). There are a limited number of hours in the day to give to the Tcl Community, so I'll use tools that make me more productive (both in terms of development and maintenance) - even at the risk of alienating a few people who don't see the need for a feature that is fundamental to most, if not all, other modern programming languages. I'll step down from my soapbox now :-)

DDG 2004-06-10: I ported the gbutton to snit in order ot use it on a MacOS 9 platform where no itcl is available. It's named snitbutton obviously.

stevel

Fixed a problem with the bindings - if the cursor is moved outside of the button after being pressed, then the associated command doesn't fire.

Thanks to Elchonon Edelson for pointing out this deficiency.

stevel 12 Nov 2002

It's not clear what the intended behavior ought to be from your description. Personally, I expect that if a button is pressed, and then the cursor is moved outside of the button, then the associated command should not fire. What is your expection? -- escargo 12 Nov 2002

Yes, that's what he's saying. Because he fixed the problem with the bindings, NOW if you move the cursor out of the button before releasing the mousebutton, the command doesn't fire. The problem was that it did. -- [EE] 20 Nov 2002

See also

Category GUI