Re: Widget states for 3.0 (and 2.18?)



On Sun, 2009-08-16 at 22:08 +0200, Kristian Rietveld wrote:
> 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?

Garnacho had done something like this in style-context branch (which
isn't in git.gnome.org yet, but which is in github in my and garnacho's
repos and which I am trying to get back to work on now).. so the style
context stores the widget state and paint_box() pulls the state from the
style context rather than passing GtkStateType as a parameter.  But so
the style context knows how to draw the widget when it's fading between
states A and B, it stores it as a bitflag.

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

So, the current style-context branch has:

GtkWidgetState
gtk_widget_get_state_flags (GtkWidget *widget);

while the current git master has:

GtkStateType
gtk_widget_get_state (GtkWidget *widget)

So, I guess my concern was that I'd like to progress with the
style-context branch soon (and I can spell out my related ideas with
this in another email soon), but I hate to add gtk_widget_get_state() in
2.18 and then ask to remove it in 3.0 and switch state flags.  So the
part I wrote about widget flags I actually meant something along the
lines of proposing to do:

gboolean gtk_widget_state_is_normal(GtkWidget *widget)
gboolean gtk_widget_state_is_active(GtkWidget *widget)
gboolean gtk_widget_state_is_prelight(GtkWidget *widget)
etc..

If we use this type of API instead of gtk_widget_get_state(), then it's
compatible with 2.x style flat enums so we could use it in 2.18 (instead
of gtk_widget_get_state) and it's compatible with bitflag style storage
that I'm proposing we use in 3.0.

/ Cody



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]