Re: GdkColormap -> GObject

[Havoc Pennington <hp redhat com>]

Karl Nelson <kenelson@ece.ucdavis.edu> writes: 
> I am much more concerned with structures such as Style where 
> we really do want to derive them but can't currently.  
>

GtkStyle is next, once I get GDK done. However I was hoping GDK would
only take a couple days and instead my first draft took a couple days
and I'm starting over now. :-( window/drawable are sort of painful.

> Not being able to derive Gdk types will likely be okay because,
> quite frankly hooking into gdk vfuncs would be very hard to do
> without proper exposure of internals in window structures.  

I'm trying to make it possible to derive GdkGC/GdkDrawable, and I
think it will work basically OK. The only real issue here is that we
need to virtualize GdkRegion in order to virtualize gdk_gc_set_clip().


For GdkColormap, on the drive home I was thinking: I'll just use a
windowing_data pointer instead of a differently-sized GdkXColormap
struct, so GdkColormap will all work as expected (but won't have any
cross-platform code).

Question: why does GObject lack a destroy() method? Should C++
bindings make destroy() a method for widgets only (in particular if
GObject doesn't have destroy(), I'm having a hard time deciding why
GtkAdjustment and GtkTooltips have a destroy(), aside from legacy
compatibility).

Havoc