From: Jim I. <ji...@ap...> - 2003-08-29 20:37:06
|
Not quite sure what you are proposing to do with this. I can guarantee you that you will not be able to get your tile widget to look like the Mac OS X button widgets without a lot more work than you want to do, and making them throb will be even harder. Plus the look of button with image and button with text are very different on X. The complexity of the button code in Tk is in large part to handle this sort of issue... Jim On Aug 29, 2003, at 11:29 AM, Joe English wrote: > > Greetings, fellow Tk maintainers! > > I invite you all to take a quick look at the implementation > of the [button], [checkbutton] and [radiobutton] widgets. > You can find it in generic/tkButton.c, library/button.tcl, > and {mac,win,unix}/tk{Mac,Win,Unix}Button.c. > > Pay special attention to the interactions between -state, > -indicatoron, -relief, -offrelief, -overrelief, -background, > -activebackground, and other resources. > > Take your time. I'll go get a cup of coffee and read /. for > a while. > > * * * > > Got all that? Kind of messy, no? > > Now I want to tell you about my secret project. I've > got a new widget, which I call a "Tile". It doesn't > do anything useful -- it's just a background and a border -- > but it can be configured to act just like a regular > (Unix-style) Tk button with the following bit of code: > > option add *Tile.takeFocus Tile::takefocus > > bind Tile <Enter> { %W state active } > bind Tile <Leave> { %W state !active } > bind Tile <FocusIn> { %W state focus } > bind Tile <FocusOut> { %W state !focus } > > bind Tile <KeyPress-space> { Tile::activate %W } > > bind Tile <ButtonPress-1> { %W state pressed } > bind Tile <Button1-Leave> { %W state {!pressed !active} } > bind Tile <Button1-Enter> { %W state {pressed active} } > bind Tile <ButtonRelease-1> { > %W instate {!disabled pressed} { Tile::invoke %W } > %W state !pressed > } > > > Those bindings call a few helper procedures, which I ought > to show as well: > > namespace eval Tile { > proc takefocus {w} { > return [$w instate !disabled] > } > proc invoke {w} { > $w instate disabled { return } > puts "Invoked $w" > } > proc activate {w} { > $w instate disabled { return } > set oldState [$w state {active pressed}] > update idletasks > after 100 > $w state $oldState > after idle [list Tile::invoke $w] > } > } > > Now here's the neat part: the dynamic look and feel is controlled > by the following: > > option add *Tile.settings { > -background { > disabled #d9d9d9 > active #ececec > {} #d9d9d9 > } > -foreground { > disabled #a3a3a3 > {} #000000 > } > -relief { > {pressed !disabled} sunken > {} raised > } > -highlightcolor { > focus black > !focus #d9d9d9 > } > } > > That's for a conventional button like those in dialog boxes. > To make it act like a toolbar-style button, you can say: > > $tile configure -settings { > -relief { > disabled flat > pressed sunken > active raised > {} flat > } > -background { > disabled #d9d9d9 > active #ececec > {} #d9d9d9 > } > -foreground { > disabled #a3a3a3 > {} #000000 > } > -highlightcolor { > focus black > !focus #d9d9d9 > } > } > > > The basic idea is to replace the -state resource (an > enumerated value) with a bitmask. Valid bits are > currently: > > active -- the mouse cursor is over the widget > focus -- the widget has keyboard focus > pressed -- the widget is "pressed" or "armed" > disabled -- widget is disabled under program control > > [$w state $spec] modifies the widget state; $spec > is a list of symbolic state names, optionally prefixed > by an exclamation point. [$w state $s] turns the $s bit > on, [$w state !$s] turns it off. State names which are > not mentioned in $spec are left as-is. [$w state $spec] > returns the previous state of all bits mentioned in $spec > (this is used in, e.g., Tile::activate to restore the > previous state). > > [$w instate $spec] returns true if the current widget state > matches $spec; [$w instate $spec $script] is shorthand > for [if {[$w instate $spec]} $script]. > > The -settings resource (which really needs a better name) > is a dictionary mapping resource names to lists of statespec / value > pairs. Whenever the state changes, each resource is set > to the value corresponding to the first matching statespec. > > If you want to play with this, a snapshot is available here: > > <URL: http://www.flightlab.com/~joe/tile-0.1-2003-08-29.tar.gz > > > Usual caveats apply: pre-alpha experimental code, no warranties, > few comments and no documentation, yadda yadda yadda. I'm > still working on it... > > Other notes: the Tile widget uses the TIP 48 style engine > (more on that later), so even if the above doesn't interest > you the style engine bits might. > > > --Joe English > > jen...@fl... > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > -- Jim Ingham ji...@ap... Developer Tools Apple Computer |