Re: Tk::FunkyButton ?

Ala Qumsieh wrote:
> --- Dean Arnold <[email protected]> wrote:
> 
> 
>>To do "styled" buttons:
>>

<snip>

>>
>>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.

Hmm, hadn't thought of that, tho I rarely pack a button to fill,
and wouldn't use my "styled" buttons that way.

> 
> 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.

Agreed. Alas, pTk is a bit lacking in the area of runtime
image generation. I've been generating gradients a line
at a time in a canvas for styled button purposes, but the
thought that each line is a full blown canvas object that
eventually has to be grouped into a single managed object
concerns me is a bit. So I'll likely end up requiring
GD be installed so I can render images w/ a bit less
overhead (just create a gradient brush the width of
the button, and drawn the line, resulting in a single
image).

> 
> 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.
> 

While I personally agree w/ you, I have been edified (by recent
experiences w/ my end users) that user i/f expectations
are changing. If the app's GUI doesn't have lots of chrome, despite
any functional advantages the app itself may provide, it often
meets with user resistance. E.g., some folks need D&D, autocompletion,
syntax hilighting, etc....things I rarely use (and some often annoy me).
But, in order to get user acceptance, its easier to switch than fight,
*if* I can figure out how to provide the chrome w/ a modest effort.
Plus I'm not really trying to create a new widget, but simply extending the
look/feel options available to existing widgets.

And, I'll add, after rendering some of the gradients, they do
look rather sexy...;^)

- Dean
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 [email protected]