GNOME Bugzilla – Bug 702563
gtk_widget_class_automate_child() takes private offset
Last modified: 2013-07-26 13:17:13 UTC
gtk_widget_class_automate_child should take an offset relative to the _instance_ pointer rather than the private pointer. These days, private pointers are at a constant offset to the instance which is a change that we made so that GProperty could remove this instance/private distinction. Doing it this way would solve a very very common case: people who want to use this stuff to build their main window and have the children as pointers on their instance, without creating a private struct (which is semi-pointless since they're not doing libraries).
Created attachment 248212 [details] [review] widget: Use a real offset in gtk_widget_class_automate_child Using an offset from the struct means you can have children in both the public and private (via G_PRIVATE_OFFSET) parts of the instance. It also matches the new private macros nicer. This is a WIP and not yet tested, because it doesn't work until all users are converted to use the new _WITH_PRIVATE/ADD_PRIVATE setup.
Created attachment 248428 [details] [review] widget: Use a real offset in gtk_widget_class_automate_child / v2.0 same patch as Alex's, but this one has all the call sites updated, plus the correct check on the field offset not being zero, instead of it being positive (as the private offset is negative). tested on master, and it works pretty nicely.
forgot to say: this patch depends on the patchset for bug 702996 which transitions all GTK classes to the new private macros and offset-based access.
Review of attachment 248428 [details] [review]: Looks pretty straight forward. With the last issue fixed, checking for 'child_class->offset != 0', the patch looks perfectly safe to me. Marking as commit-now (but of course it still depends on, yet another uncommitted patch). I'll try to keep my eye on this, when these patches land we should announce it on gtk-devel-list, as there are a couple of projects already using this API.
Note in particular that Vala is codegening to this API.
(In reply to comment #5) > Note in particular that Vala is codegening to this API. yes, I've already talked to Lethalman on #vala about the changes, including the ones for bug 700898 (and discovered a bug in the Vala implementation in the process that would be fixed by this patch).
we *really* need to land this before the 3.10 freeze date, otherwise we're going to be stuck with the current API.