Re: [gtk-list] Re: Advice requested for a would-be patch on gtkmenufactory

[Tero Pulkkinen <terop students cc tut fi>]

hmm, I wonder if gtk-list has some spam filter or something, I couldnt get
my mails go to the list for some reason :( Hope this one goes fine...

> > I'd like to submit a patch on gtkmenufactory to make
> > gtk_menu_factory_create, gtk_menu_factory_remove and
> > gtk_menu_factory_make_widget non-static.

Owen Taylor <owt1@cornell.edu> writes:
> Well, you could just use (for gtk_menu_factory_create)
> 
>   gtk_menu_factory_create (factory, &entry, 1);
>   gtk_menu_factory_remove_paths (factory, &entry, 1);
> 
> Which would probably remove the need to make  gtk_menu_factory_create.
> 
> > The reason is that I need them in a new, more C++-ish, menufactory
> > class that I've written for gtk--.
> 
> Hmmm .. I'm not sure I like the approach of making gtk-- dependent on
> the internals of GTK. It would be nice to be able to change the
> internals of the widgets without having to worry about breaking
> things.

gtk-- unfortunately already relies on internals of GTK :(. Every widget
derived from any gtk widget needs to cut/paste the gtk_*_new() method,
and thus every gtk-- widget has cut/pasted it. (this is because the
gtk_*_new() methods fix the type of the constructed object.)

Also, because some of those gtk_*_new() methods (like for curve and
scrolledwindow) call static methods, either the static methods need
to be cut/pasted, or the derived widget is not working the way it
should work.

> > Since I'm not sure how good this reason is (and may be those functions
> > were made static for a better one), I'm asking around first before
> > uploading my patch. :-) So if anyone sees any reason why this
> > functions should remain static, please tell me so.
> 
> Well, one problem is that you'll break the encapsulation of
> the menufactory widget. gtk_menu_factory_create has a pre-condition
> that factory->widget exists. If you removed that pre-condition,
> (i.e., check in _create, and create the widget if necessary)
> it probably would be OK. (Similarly for _remove).

Making a function nonstatic is better than cut/paste the code of it :)

Tho of course it'd be much better if the parts of gtk_*_new() methods
that rely on the exact type of the widget be separated from the actual
implementation code of "constructor"...

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