Re: Widget states for 3.0 (and 2.18?)

Jumping in here from a practical perspective, please correct me if I am wrong ;)

On Mon, Aug 17, 2009 at 5:42 PM, Cody Russell<bratsche gnome org> wrote:
>> This is not how it works in GTK+. The "checked" state is indicated by
>> the GtkShadowType passed to the drawing function (gtk_paint_check),
>> where:
> Right, but I guess that's part of the point of all this.  Wouldn't it make
> more sense if we try to move this type of information into a single location
> instead of having these kind of work-arounds?
> I'm not suggesting we change how things work in 2.18, but in 3.0.  But I'm
> bringing it up now because we're adding gtk_widget_get_state() to take over
> for the GSEAL'd widget->state member.  If we avoid this and introduce APIs
> for each widget state instead then we have time to revise how it works
> internally for 3.0 without breaking a newly-introduced API.

But still we need a compatible accessor for the old state field in
2.90 (and thus 3.0).  I think there is no other way than to add
gtk_widget_get_state() for now.  Instead introducing a function for
each widget state will result in a much more involved transition.
Could this gtk_widget_get_state() function serve as the mutually
exclusive data set as suggested by Thomas?  The non-mutually exclusive
data set would be introduced at a later stage (3.0) and next to



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