Re: Steps to get to GTK+ 3.0

[Stefan Kost <ensonic hora-obscura de>]

hi,

Felipe Contreras schrieb:
> On Tue, Jun 3, 2008 at 3:23 PM, Tim Janik <timj imendio com> wrote:
> > On Tue, 3 Jun 2008, Alberto Mardegan wrote:
> >
> > > ext Kristian Rietveld wrote:
> > > > 10. Remove all structure fields from the public API.  There are two ways
> > > > this can be done:
> > > >   a) Move object structures to private headers.
> > > >   b) Move object structures to the local C file, the rest of GTK+ will then
> > > >      also have to use accessors.
> > > If you go for (a), will the private headers be installed in the target
> > > system?
> > No, definitely not. "private headers" here means "internal", in that they'll
> > be accessible only from within the Gtk+ source tree during the gdk and gtk
> > library builds.
> >
> > > I've often felt that subclassing a GTK+ widget to modify its
> > > functionality is usually harder than creating a new widget from scratch
> > > (copying from the GTK+ code), as accessing the parent private members is
> > > impossible, and many members that could be useful for a derived class
> > > are in the private struct.
> > >
> > > I like the Python way of doing it (by mangling the members name you want
> > > to protect, so the client must really know what he's doing when
> > > accessing it); I would find it useful if private GTK+ were private but
> > > somehow accessible (at least from derived classes).
> > This would essentially make the fields part of our (semi-)public API,
> > and that in turn means we need to preserve their behaviour compatibly.
> > This is something we cannot provide and which gets us into much trouble
> > currently when we try to fix bugs or optimize/improve the current code
> > base.
>
> So how should people create extra functionality? For example, I
> extended GHashTable creating a g_hash_table_peek_first function, for
> which I needed the private fields. So I had to create fake structures
> with the same fields just to access them. I know that's dirty, but it
> works, and creating my own hash table just to add that function wasn't
> appealing.
>
> What about publicly stating that including foo_private.h is looking
> for trouble, and perhaps foo_protected.h for objects that inherit.
>
> I'm just dumping ideas, I don't know what's the proper solution, but I
> definitely see obstacles to re-use current objects/widgets.
>
> Best regards.

The proper solution in the above case is to submit a patch that adds 
g_hash_table_peek_first to the GHashtable :)

Stefan