--- Dean Arnold <darnold@xxxxxxxxxxxxxx> wrote:
> To do "styled" buttons:
>
> 1. generate button image(s), using either
> static image files, or at runtime using
> <insert favorite graphics package here, e.g., GD>
>
> 2. Create borderless button widgets
>
> 3. Use a -command callback that
> explicitly reads the current mouse position
> and ignores the button press/release events
> unless its over the desired image area
> (or the button has keyboard focus)
>
> 4. (Optional) swap button images on press/release,
> and/or on Motion, FocusIn and FocusOut events,
> for a rollover effect
>
> Is that the gist of your statement ?
Not really, I'm not THAT smart :)
The problem with image-based buttons, as far as I can
see, is that the size has to be hard-coded. For
example, if the button is packed with '-fill => x' and
the window is resized, then the image needs to
dynamically change to accomodate.
As for my comment in the previous post, I really meant
that the Canvas is a very heavy object, compared to a
simple Button, and using multiple Canvases to emulate
buttons will incur additional, and perhaps
unnecessary, memory usage. I don't think speed would
be a big issue, but we need to do more tests to
quantify that.
I'm not a fan of flashy, out-of-the-ordinary
interfaces. I believe that, generally speaking,
non-standard widgets, like oval button for example,
give users a sense of unfamiliarity, and alienates
them from the interface. This can have a negative
effect on the popularity of the interface.
This doesn't mean that we should confine ourselves to
the given set of widgets all the time. There are
cases, of course, when a newly created widget offers a
far more superior solution than existing ones. Those
cases are very few, though, and coming up with a new
widget that is intuitive and simple to use can be a
challenge.
--Ala
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server. If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ptk" to majordomo@xxxxxxxxxxxxxxxxxx
|
