Re: enhacing GTK visual quality



-> 1) When a label gets an allocation space inferior to the requested by
-> the widget label,
[...]
-> |--------------|
-> |ust to big label to fi|	
-> |--------------|
-> 
-> The right thing:
-> 
-> |--------------|
-> |... to big label to  f...|
-> |--------------|

	Question: Is the above example only when the label is centered?
If the label is left-aligned, I would expect

-> |--------------|
-> |Just to big label to fit
-> |--------------|

	to become

-> |--------------|
-> |Just to big...|
-> |--------------|

	...and if the label is right-aligned, I would expect

-> |--------------|
->big label to fit|
-> |--------------|

	to become 

-> |--------------|
-> |...abel to fit|
-> |--------------|

	Finally, MS-Windows will present the entire label as a tooltip if
the user puts the mouse over the obscured label.  That is, the label is
superimposed on top of the obscuring window, with a yellow background, so
the user can see what the label is trying to say.

	Although that solution looks rather crappy, it is a very practical
feature (especially when looking at a list of long directory pathnames or
some such thing).  Shrink the left-side tree of Windows Explorer to see
what I mean.

	It would be cool if we could come up with something a little more
aesthetically pleasing, but functionally equivalent.  Maybe a
mini-animation to "peel back" the obscuring part of the window on top, or
maybe make the obscuring window shaded and translucent just in the area of
the label (so the user can "see through" to the obscured label).  How does
Mac OS X handle this (if at all)?


-> 2) The long and interminable story of the buttons don't getting
-> depressed (visually) when the users click on them using the keyboard

	This has come up before.


--Derek






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]