Thoughts on an INACTIVATE state

[Owen Taylor <otaylor redhat com>]

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.) 
Examples:

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

 - The concept was recently added to Qt to support "mac-like"
   themes.

 - The eazel-engine and Crux theme try to emulate this 
   behavior, though it seems rather unreliable as currently
   implemented.

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:

     GTK_STATE_NORMAL,
     GTK_STATE_ACTIVE,
     GTK_STATE_PRELIGHT,
     GTK_STATE_SELECTED,
     GTK_STATE_INSENSITIVE

    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.

    Advantages:

     - Conceptually clean

     - Fits well into the current RC file syntax

    Disadvantages:

     - There could be code like:

       ===
       GdkGC *gc;
 
       switch (widget->state)
         {
           case GTK_STATE_NORMAL:
           gc = foo_gc;
           break;
           [...]
         case GTK_STATE_ACTIVE:
           gc = base_gc;
           break;
         }

       [ 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 
      inactive windows.)

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

    Advantages:

     - Really, really, simple to implement, won't break anything.

    Disavantages:

     - Inefficient

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

    Advantages:

     - Could be a very powerful mechanism to have
    
     - Allows almost anything to be changed. 

     - Unlikely to break anything
 
    Disadvantages:

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

Regards,
                                        Owen