Thoughts on an INACTIVATE state
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list gtk org
- Subject: Thoughts on an INACTIVATE state
- Date: 03 Mar 2001 20:45:42 -0500
In some cases, people want to draw widgets within unfocused
toplevels in a different style than widgets within focused
toplevels. (I'll use the term active/inactive for this,
though it's rather confusing with GTK_STATE_ACTIVE.)
- The Macintosh UI has traditionally done this. (Probably
inspired by the fact that switching between apps on the
Macintosh is more of a major transition than on other
- The concept was recently added to Qt to support "mac-like"
- The eazel-engine and Crux theme try to emulate this
behavior, though it seems rather unreliable as currently
I think it would be nice to support this in GTK+ (though
certainly not essential), but it's not clear to me quite
how it would best work. A few possibilities come to mind:
1) Extend the GtkStateType enumeration:
With GTK_STATE_INACTIVE, and then, when a toplevel becomes
inactive, go through and change all widgets in GTK_STATE_NORMAL
to GTK_STATE_INACTIVE, and the reverse when it becomes active.
- Conceptually clean
- Fits well into the current RC file syntax
- There could be code like:
gc = foo_gc;
gc = base_gc;
[ Use gc ]
GCC is pretty good about catching this, but only if people
are careful to always use the GtkStateType type.
- There is no way to distinguishing active/non-active
for the SELECTED state. (It doesn't matter for
ACTIVE/PRELIGHT, since they are used, basically,
only for temporary conditions that won't occur in
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.
Themes would be responsible for checking the widget argument
- Really, really, simple to implement, won't break anything.
- Conceptually ugly
- Doesn't allow inactive colors to be specified in the
RC file for the default theme.
3) Extend the style binding mechanism to allow style switching
based on whether the toplevel is active/inactive.
- Could be a very powerful mechanism to have
- Allows almost anything to be changed.
- Unlikely to break anything
- Really inefficient; switching styles requires a size-allocate,
not just a redraw; widgets may do complicated things when
they get a ::style_set signal.
- RC files don't need to get more complicated
So, how much are you dying to have this feature? and does anybody
have any better ideas about how to do it?
] [Thread Prev