Hey there, I am still a bit confused ;)
On Sun, Aug 16, 2009 at 9:45 PM, Cody Russell<[email protected]> 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. _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
