Re: an additional argument flag

[Owen Taylor <owt1 cornell edu>]

Tero Pulkkinen <terop@students.cc.tut.fi> writes:

> > > Therefore, either we duplicate all the "widget setup" code in each
> > > _new() into the gtk-- constructors (which is what we currently do,
> > > since it's quite tolerable for most widgets), or we get a new entry
> > > point in the construction chain right after the call to
> > > gtk_type_new().
> 
> Owen Taylor <owt1@cornell.edu> writes:
> > Hmmm, some day I'm going to have to take a look at gtk-- and see
> > what is going on there. I get the feeling that there is some
> > horrible perversion of the GTK type system going on there. ;-)
> > 
> > Does gtk-- actually _change_ the type of the created widget. I don't
> > see how this is necessary, or how it can successfully be integrated
> > with normal GTK+ code.
> 
> For overriding virtual methods from C widgets, gtk-- "derives" from every
> 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.

Interesting. Does gtk-- handle widgets that are not created ny
gtk-- correctly? (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?)

[...]

>      * Calling Gtk_Object::destroy starts the following
>        function calls:
>        * Gtk_Object::destroy()    (called by user)
>         * gtk_object_destroy(o)   (see  NOTE1 below)
>         * Gtk_Object::destroy_callback(o) (see NOTE2 below)
>         * Gtk_Object::destroy_impl()
>         * gtk_real_object_destroy(o) (see NOTE3 below)
> 
>       And this way, by overriding the destroy_impl function does work
>       as supposed.
> 
>   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. 

Thanks for the explanation. I think I understand the basics of
gtk-- now...

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

Regards,
                                        Owen