Re: Widget states for 3.0 (and 2.18?)

[Kristian Rietveld <kris gtk org>]

Hey there,

I am still a bit confused ;)

On Sun, Aug 16, 2009 at 9:45 PM, Cody Russell<bratsche gnome org> wrote:
> In the Dublin hackfest, one idea that came up for 3.0 was to switch from
> an enumerated GtkStateType to a bitflag type so it's possible to support
> multiple states at a time.  One of the main reasons for this was related
> to state-changing animations, but in general it just seems to make sense
> that we can support multiple states on a widget at a time.

As soon as the number of states is extended, I can see that it might
start making sense to support multiple states at a time.  How would
state-changing animations work?  From a bitfield I cannot really make
up from which to which state to change?

> So now I'm questioning whether it makes sense to have
> gtk_widget_get_state() at all, and perhaps we should only have the
> individual get/set methods for each state bit.  Then in 3.0 we could
> make a switch to a bitflag state system instead of a flat enum.

So the only question remaining is whether or not to have
gtk_widget_get_state().  The comment about get/set methods for state
bits must be specific to the widget flags ;)  I would say that for 3.0
we *need* an accessor for state, and I cannot see a different way to
implement it than doing a gtk_widget_get_state() with an enum return
value.  Later on, it will most probably be deprecated and
re-implemented as a transform from the new bitfield to the deprecated
enum.


regards,

-kris.