Re: Pluggable widget types and implementations
- From: Tim Janik <timj imendio com>
- To: Murray Cumming <murrayc murrayc com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, Ross Burton <ross burtonini com>
- Subject: Re: Pluggable widget types and implementations
- Date: Tue, 28 Nov 2006 18:41:23 +0100 (CET)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]