Re: Pluggable widgets II

[Tim Janik <timj imendio com>]

On Wed, 20 Dec 2006, Tristan Van Berkom wrote:

> On Wed, 2006-12-20 at 15:34 +0100, Tim Janik wrote:
> > > 	My point is that Foo would prefer if PanelMenu could automatically
> > > sub-class FooGtkMenu rather than GtkMenu.
> >
> > with Gtk+ and its object system, that is simply not technically possible.
>
> custom_menu_item_type =
>    g_type_register_static
>            (g_factory_get_appointed (GTK_TYPE_MENU_ITEM),
>             "CustomMenuItem",
>             &custom_menuitem_info, 0);

this breaks badly as you add fields to a type appointed for GtkMenuItem.
also, you may depend on a particular base class behavior when deriving
currently. if you break that by exchanging base classes freely, things can
break in very subtle places and very subtle ways. and this breakage
may possibly only occour at the users machine where theme settings,
installed module base, arch type, etc. will determine the final
class combination.

the relationship between parent and child classes in general is not modular
and encapsulated enough in Gtk+ to allow this type of reconfigurability.

> I've done some experimenting with subclassing of dynamic types
> (or "types that may vary" for lack of better words).
>
> In Glade, I use a GladeWidgetAdaptorClass to interface with the plugin,
> the core proceeds to load C functions from the backend modules for each
> supported class and then the core uses this to programaticly derive
> the base adaptor class with dynamicly created subclasses -
> it been working fine.
>
> At first thought, assuming that:
>   g_type_is_a (g_factory_get_appointed (TYPE_FOO), TYPE_FOO);
> (which Tim reassured me of in another email), then I believe
> there should be no problems if the PanelMenuItem went ahead
> and subclassed an appointed type directly - since that appointed
> type must conform to the original type.

there is no way this is going to work matainably with an open inheritance
style such as ours, see:
  http://martinfowler.com/bliki/OpenInheritance.html

the only reason you can do this in glade (control it and maintain it) is
that you have close control over both, the base classes and the derived
classes at the same time.

> The remaining obvious problem however, is to ensure that the vendor did
> in fact appoint its chosen type to the menu item *before* the
> panelmenuitem goes ahead and registers its type.

using modules this wouldn't be a problem since they are loaded at
gtk startup time. it's not possible for other reasons outlined above though.

> Cheers,
>                        -Tristan

---
ciaoTJ