Re: 3.0-related deprecations

[Kristian Rietveld <kris gtk org>]

Hi Cody,

On Sun, May 10, 2009 at 12:19 AM, Cody Russell <bratsche gnome org> wrote:
> gtk+ currently does not build with GSEAL enabled, and I want to remedy
> this so we can make progress on 3.0.  I'm planning to post a large
> series of patches unless someone has a suggestion for how better to do
> proceed with this.

In the "original" plan[1] this was actually one of the last things to
tackle, after the preparative work has been done.  It was slated to
happen on a branch, and after all 2.x-deprecated code has been
removed.  At the time, we saw two ways to remove the structure fields
from GTK+ (which is for now the same as enabling the GSEAL macro):

 a) Move object structure definitions to private headers.  The private
headers would be shared amongst the GTK+ source files.  This approach
does not require GTK+ source code to be changed.

 b) Move object structure definitions local to the respective C file.
For this approach, the rest of GTK+ will have to be adapted to use
accessors, as your patch does for GtkWindow.  For larger "components"
inside GTK+ (think GtkTreeView, GtkFileChooser) we could choose to
share the structure definitions between the component's source files
(kind of like GtkTreeView currently does via gtktreeprivate.h).

> I've posted the first patch[1] and it's about 105k, although it
> shouldn't really be a big burden to review.. it adds 5 new API functions
> for public struct members that didn't previously have API, otherwise
> there's not much of interest in it.  I used the code rewriter to
> generate parts of it, but had to insert all the "GtkPrivate *priv =
> GTK_WINDOW_GET_PRIVATE (window)" type stuff somewhat manually.

As you have noted there are still accessor methods missing.  For some
of these fields an accessor has deliberately not been added as the
field was considered private.  There are also fields for which it
wasn't really known whether it was considered public or private and is
still up for dispute ;)  Your approach of adding accessors for things
that is depended upon elsewhere in GTK+ sounds plausible -- although I
think there could be exceptions.

> Last thing is what to do with this stuff.  Assuming someone is able and
> willing to review it, should it go in git HEAD or should we make another
> branch for it?  My preference is to just put it in git HEAD probably.

Maybe it is best to put this on a new branch and experiment a bit to
see how things should be done.  However, as the original code
continues to move it will probably become a pain in the ass to
maintain the branch.  (This is basically why this work was one of the
last items on the plan ;).

I really hope to chime in and help out at some point (when school's done) ...


regards,

-kris.


[1] http://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00014.html
or in the wiki:  http://live.gnome.org/GTK%2B/3.0/Tasks