Yeah, you are rigth. I just want to commit the rest of the patch ASAP (because it affects a lot of code) before raise this issue.

The problem is that when moving the private flags all the private macros stop to work, see http://git.gnome.org/browse/gtk+/tree/gtk/gtkprivate.h#n56

So what would be the best solution here? Add a new private accessor to access the private flags? move the private flags to gtkprivate? Or maybe not move the widget private flags?

Note that we already have the GtkObjectFlags, that should be moved to gtkobjectprivate or maybe to gtkprivate too? (see bug #615666 for discussion about this issue)

I think private flags could all just become regular booleans, like have:

guint resize_pending : 1;
guint in_reparent : 1;

for the ones used outside of gtkwidget.c you'd have to add accessors and possibly even properties. private_flags seems pretty simple this way.
The old macros could be defined compatibly to just use the accessors instead:

#define GTK_WIDGET_USER_STYLE(widget) gtk_widget_get_has_user_style(widget)
etc.

object flags are a bit different because there's a reason to use flags: so that GtkWidget can share the same 32 bits. If you do 
guint mapped : 1; 

in gtkwidgetprivate, then that won't be inside the 32 bits that GtkObject already used up. Also of course the public widget flags are possibly used in more places, so more reason to stay backward compatible.

You could probably privatize the "guint32 flags" in GtkObject, and then use an accessor to get/set them. That would add a GtkObjectPrivate *priv to the GtkObject struct though, which would waste even more space than just moving all the widget flags to widget.

I think I'd tend to say, these space concerns are sort of bogus, given how huge GtkWidget already is, and that GtkObject isn't used for much besides widget. So maybe I'd tend to just add GtkObjectPrivate, put in_destruction into GtkObjectPrivate, then put all the public widget flags into GtkWidgetPrivate and add accessors.

But maybe keep the old flags macros working (they'd just use new accessors, instead of actually using a flags integer),
have a function gtk_widget_set_flags(), do 
#define GTK_WIDGET_SET_FLAGS(widget, flags) gtk_widget_set_flags(widget, flags)

and then gtk_widget_set_flags() would just call the accessors, like:

if (flags & GTK_WIDGET_FLAG_FOO)
 gtk_widget_set_foo(TRUE)

etc.

just ideas, you probably need to know what Matthias thinks.

The GtkObject docs state that

"GtkObject predates GObject; non-widgets that derive from GtkObject rather than GObject do so for backward compatibility reasons."

So, one idea would be to move the non-widget classes that currently derive from GtkObject to GInitiallyUnowned and merge the destroy functionality into GtkWidget.

No more GtkObject, no more flag wastage...

Indeed, though you might have to switch some destroy signal handlers to GObject weak refs

(In reply to comment #3)
> So, one idea would be to move the non-widget classes that currently derive from
> GtkObject to GInitiallyUnowned and merge the destroy functionality into
> GtkWidget.

Patch filled in bug #629729

See the gtkobject-removal branch