Re: Pluggable widget types and implementations

[Tim Janik <timj imendio com>]

On Tue, 28 Nov 2006, Murray Cumming wrote:

> On Tue, 2006-11-28 at 15:03 +0000, Ross Burton wrote:
> > On Tue, 2006-11-28 at 14:53 +0100, Tim Janik wrote:
> > > Resulting in gtk_file_selection_new() to return objects of the custom type
> > > gtkfileselector_derived_type, and gtk_printer_selection_new() to return
> > > objects of the custom type iface_implementation_type.
> >
> > How would this interact with libglade/GtkBuilder, where dialogs are
> > created at runtime?  I'm guessing that GtkBuilder uses g_object_new() to
> > construct the objects.
>
> This would also be an issue for language bindings. By convention, the
> _new() functions are considered as mere C convenience functions, and
> many language bindings (and some C applications) just use g_object_new()
> directly.

i guess that depends on whether the language binding means to provide a
function LB_create_exactly_type_foo(), which would remain to be a call
to g_object_new (TYPE_FOO, NULL); or whether it wants to provide
LB_create_compatible_with_type_foo(), which would be gtk_foo_new().

> If you want to replace implementations of GTypes, I think it would be
> simplest to change the associations inside the GType system.

this would break perfectly valid assumptions like:
  G_TYPE_FROM_INSTANCE (g_object_new (TYPE_FOO, NULL)) == TYPE_FOO.
same for classes, etc.

if at all, this would have to be a new libgobject function, like
(brainstorming some here):

  g_factory_create (TYPE_FOO, NULL); // returns TYPE_FOO object

  g_factory_appoint_type (TYPE_FOO, TYPE_BAR); // TYPE_BAR is_a TYPE_FOO

  g_factory_create (TYPE_FOO, NULL); // now returns TYPE_BAR object

> --
> Murray Cumming

---
ciaoTJ