Re: Pluggable widget types and implementations

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]