Re: GdkColormap -> GObject

[Havoc Pennington <hp redhat com>]

Hmm, I just finished implementing this and posted the patch, so look
at what I have and we can go from there...

Tim Janik <timj@gtk.org> writes: 
> that's breaking with the naming conventions for API/objects,
> and will just be extremely confusing long term.

I agree but the breakage is large if you have to cast a GdkWindow to
pass it to gdk_draw_* - Owen didn't want to break that much code.

It's fairly easy to change my patch to use GdkWindow and GdkPixmap as
the names of the GObject, but it will break plenty of user code (the
breakage is trivial and perl-scriptable, people just have to add
GDK_DRAWABLE() casts all over the place, but it's still a lot of code
that breaks).

> GdkWindowClass can simply be renamed, it's not widely used
> anyways.
> gdk_drawable_alloc() needs to vanish though, and
> gdk_drawable_get_type() should prolly be renamed.

Done and done, both are in my patch.

> so we basically get:
> 
> struct _GdkWindowClass
> {
>   GObjectClass parent_class;
>   
>   void (*construct) (GdkWindowAttr *attributes,
> 	             guint          attributes_mask);
>   /* put GdkDrawableClass functions here */
> };
> 
> struct _GdkWindow
> {
>   GObject parent_instance;
> };
> 
> typedef GdkWindow      GdkDrawable;
> typedef GdkWindowClass GdkDrawableClass;
> 
> with the existing API, that'll mostly preserve source
> compatibility.
>

Looking at this quickly, I'm concerned that this introduces the same
problem I explain for GdkGC in my other mail, namely a "virtual
constructor" which creates a concrete class, with only a pure virtual
class publically visible. 

However this is the straightforward translation of the non-GObject
code.

I'm not sure how it would compare to my current patch overall, let me
think about it.

Havoc