Re: Steps to get to GTK+ 3.0

[Stefan Kost <ensonic@xxxxxxxxxxxxxxx>]

hi,

Felipe Contreras schrieb:
> On Tue, Jun 3, 2008 at 3:23 PM, Tim Janik <timj@xxxxxxxxxxx> 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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-devel-list