Re: an additional argument flag

[Tero Pulkkinen <terop students cc tut fi>]

> > gtk widget and thus it has separate type and more importantly, its own
> > virtual function table. Then in the new type's class_init, gtk--
> > replaces that existing entries in the C virtual function table with
> > functions that call C++ virtual methods (these C++ virtual methods
> > of course then call the default implementation of what the widget
> > would have done anyway..). This way, you can after derivation override
> > everything gtk provides in its widgets.

Owen Taylor <owt1@cornell.edu> writes:
> Interesting. Does gtk-- handle widgets that are not created ny
> gtk-- correctly? 

Yes, these have different virtual function table. => does not go through
C++'s virtual methods. Gtk_Fileselection uses these and there's C++
wrapper also to the children of the fileselection.

> (This seems necessary for dealing with widgets like
> Dialog that create their own children) It seems like it should
> conceptually work fine just to point a Gtk_Widget at an existing
> widget - though the typically downcasting/RTTI problems 
> presumably occur. (Can you take a GtkWidget *, create a Gtk_Widget
> for it, then narrow that to a Gtk_Button later?)

yes, GtkWidget can be converted to Gtk_Widget - but then you cannot
override the virtual methods. - happily there's no place where you
could ever override the vfunctions without deriving from Gtk_Widget.
Thus it works in every possible case.

> > 
> >   NOTE1: that isnt done correctly currently (13 Dec 97), now it calls
> >          gtk_signal_emit instead and works in most cases, not all.
> 
> I hope this has been fixed. It will cause major problems in CVS GTK. 

It is not yet fixed :( I know how to fix it, but never got time for
doing it. Guess its important to do as soon as possible. I think some
other bugs that has been reported is bbecause of this..

> > Deriving from widgets is the only thing we need to do with gtk--. No
> > black magic involved. Deriving from widgets currently requires that
> > we rewrite all *_new() methods. On some widgets this cut/paste is kinda
> > large as there is static methods called from *_new() methods :)
> 
> I think we should specify that _new() functions can't call
> any static functions - presumably by moving all initialization
> into a construct() function, instead of making everything
> non-static.

Yeah.

-- 
-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --