Re: Steps to get to GTK+ 3.0

["Felipe Contreras" <felipe contreras gmail com>]

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.

-- 
Felipe Contreras