Re: New 'GObject' as base for GtkObject?

[Havoc Pennington <hp redhat com>]

Guillaume Laurent <glaurent@worldnet.fr> writes:
> - avoid "Item" structures like GtkMenuEntry, GtkToolbarChild,
>   GnomeUIInfo, etc...
>

FWIW I think the problem with GnomeUIInfo is that a convenience API
(the static struct initializer approach) is the _only_ API. There
should be a "manual" way to do GNOME menus that still uses GNOME
preferences and stock accelerators, etc. This is one of the big warts
on gnome-libs IMO but I haven't figured out a solution yet.
It violates the "hard things possible" rule, and gtk-- is feeling it.

GtkToolbarChild simply shouldn't be the public API, there should be
accessor functions. GtkItemFactory I don't know.
 
> - abstract callbacks in some way. A callback is not necessarily a
>   function pointer.
>

This is a good idea, complicated because you also have to abstract
marshallers. Has any discussion gone in to how to do this?

What about a signal-signature->marshaller lookup table used to find
alternate marshallers.  Then an additional flag passed to
gtk_signal_connect_still_more_full() that specifies which marshaller
set to use. So default handlers and connections done with
gtk_signal_connect() use the default marshaller still. C++ bindings
could pass an instance/memberfunction pair instead of a GtkSignalFunc
to connect_still_more_full(), and then provide marshallers that 
invoked the instance/memberfunction pair.

I'm sure that won't work but I don't see why just now. ;-)

Havoc