Re: Thoughts on an INACTIVATE state

[Havoc Pennington <hp redhat com>]

Owen Taylor <otaylor redhat com> writes: 
>  1) Extend the GtkStateType enumeration:

This scares me a bit. I don't know how much stuff would break, but it
would worry me.

Also, is the state really mutually exclusive with the other states?
Maybe you need to know e.g. selected/not and also active/not.

>  2) Provide a function gtk_widget_is_active() that checks if
>     the toplevel the widget is in is active, then simply queue
>     a redraw on the toplevel when it gets or looses focus.
> 
... 
>     Disavantages:
> 
>      - Inefficient

Doesn't seem especially so - you walk up the widget tree, which is a
super-fast while (widget->parent) loop, then check a flag. Faster than
most other stuff involved in the render pipeline. It's conceptually
O(n) sure but n will never exceed a couple dozen.

>      - Conceptually ugly
> 
>      - Doesn't allow inactive colors to be specified in the
>        RC file for the default theme.

But yes, those are true.

>  3) Extend the style binding mechanism to allow style switching
>     based on whether the toplevel is active/inactive.
... 
>      - Really inefficient; switching styles requires a size-allocate,
>        not just a redraw; widgets may do complicated things when 
>        they get a ::style_set signal.

This one is defintely inefficient.
 
> So, how much are you dying to have this feature? and does anybody
> have any better ideas about how to do it?
> 

Alpha blend a white rectangle over the entire toplevel using Xrender, 
so it appears faded. ;-) j/k

1) is almost certainly right, if it doesn't break too much stuff.

Havoc