Re: GdkColormap -> GObject

[Karl Nelson <kenelson ece ucdavis edu>]

> 
> 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.

Likely, but still adding something like that flag will only encourage
people to mark things underivable.  We have enough problems with
things like GtkClock which can't be derived because they access
a bunch of static functions from their _new function, without the 
user choosing to make something underivable.

I am much more concerned with structures such as Style where 
we really do want to derive them but can't currently.  

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.  
However, I think placing a hack just to rule it out is gross.
It is very hard to predict what the user will want to do.

( My current plan is to wrap all gdk types without virtuals using
a second system.  However, I don't want to rule out the possibility
that some gdk types will need to derive.)

As for possible remedies I suggest only considering them if they
don't cause performance hits.  If some virtual is really only derived
for windowing system and wrappers can't implement new windowing system
then it is likely okay.  Hopefully, we can accomplish what we need 
with a data element with a destroy function.   

--Karl