Re: Widget states for 3.0 (and 2.18?)
- From: Kristian Rietveld <kris gtk org>
- To: Cody Russell <bratsche gnome org>
- Cc: gtk-devel-list gnome org
- Subject: Re: Widget states for 3.0 (and 2.18?)
- Date: Wed, 19 Aug 2009 13:16:45 +0200
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
gtk_widget_set_state().
regards,
-kris.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]