Re: GdkColormap -> GObject

[Havoc Pennington <hp redhat com>]

Karl Nelson <kenelson@ece.ucdavis.edu> writes:
> 
> This is a bad idea.  Gtk-- currently has to derive things once
> to install hooks if it needs it.  If you add flags like that
> then we would not be able to use that same mechanism on all
> types.
> 

The flag doesn't change whether you can derive a proxy GObject; you
already can't derive because the GdkXColormap struct is in a
window-system-specific header, and you need to know
sizeof(GdkXColormap) in order to derive.  Well, you could make gtk--
know which window system it's on, but that's already major pain.

There are no virtual functions, so you don't need a proxy class. 
I would guess that not using a proxy class is easier than making gtk--
know about the current windowing system.

(As an aside, don't get too excited because you already won't be able
to use an unmodified code generator on GDK types the way things
currently stand, because there are broken conventions (such as
GdkWindow/Drawable/Pixmap having weird names). There's also legacy
cruft in the whole system, such as the continued existence of
GtkObject and the fact that it has a destroy() method but GObject
doesn't.)

One possible solution for colormap:
 - make GdkColormap contain a pointer to window-system-specific data,
   which subclasses can use instead of changing the struct size
 - make GdkColormap a real type, present cross-platform
 - have a GdkNativeColormap on each platform, which adds
   X or windows specific data members to the GdkColormap
   "windowing_data" field and implements the giant colormap vtable
 - sizeof (GdkNativeColormap) is guaranteed to be equal to sizeof
   (GdkColormap), so that gtk-- and other wrappers don't have to
   include the window-system-specific headers to get
   sizeof(GdkNativeColormap)
 - gdk_native_colormap_get_type() is exported in cross-platform 
   headers for use by language bindings
 - gdk_colormap_new() returns a GdkNativeColormap cast to GdkColormap

Some issues with that are: giant vtable is basically useless to 
users, it's just an implementation detail, so maybe not worth
implementing; and gdk_colormap_new() is quite broken.

Havoc