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

[Owen Taylor <owt1 cornell edu>]

Guillaume Laurent <glaurent@worldnet.fr> writes:

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

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.
 
It would also be nice to keep all the different language bindings
as consistent as possible with GTK. Otherwise, only experts
in a particular language binding will be able to answer questions
by users of that binding. But I suppose the menufactory is
tied to C callbacks, so it probably does need a separate interface
for other languages. 

The internals of GtkMenuFactory probably should be rewritten to
conform to the standard callback interface - and the current C
interface should just be a layer on top. (i.e., we need
a gtk_menu_factory_create_interp, etc.)

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

But I think you probably could just use the approach mentioned at
the top. The overhead is pretty low.

Regards,
                                        Owen