Re: vertical scale display; button prelighting

[Paul Davis <pbd Op Net>]

Owen writes:

>Consider the case of a child widget of a button, and I think you'll
>see that toolkit involvement in the propagation of the PRELIGHT state
>is necessary.

>P.S. - the prelight state indicates not the "mouse cursor location",
>       but that the location where the mouse is active and responsive
>       to clicking. 

Is there any reason (or occasion, even) why the widget in which the
mouse cursor is visibly located is not the widget that will respond to
a button press/release/click, AND that state is indicated by PRELIGHT,
given that PRELIGHT seems to be universally driven by {enter,leave}_notify?
 
I mean, I know that a menu will still "respond" to a button event when
the cursor is no longer on it, but PRELIGHT is not used to indicate
that, AFAIK.

>The idea of a user setting (a programatic setting is indeed
>non-sensical), would be that the button widget would obey the setting
>and not put itself into the PRELIGHT state. If you read gtkbutton.c,
>you'll see that GtkButton is putting itself into the prelight state in
>response to enter/exit.

Excellent point, and one that I ignored. So, I blame the individual
widgets now, as well as the toolkit! :))

Well, at least we could fix the widgets on a case by case basis, as
needed. Buttons are by far the worst offenders, though there are
others as well.

>Of course, with GTK+-2.0, setting the color of the prelight to the
>same as the normal color works quite nicely for disabling prelight.

Even for a toggle button with two different colors for active/normal?

>Its also quite conceivable to me that someone would want the subtle
>changing coloration of toolbar icons effect, but not the larger
>changes of background color, so I'm not sure that a global toggle of
>prelight is the right way to configure this.

You really want infinite flexibility?

--p