[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Pluggable widget types and implementations
From:       Tim Janik <timj () imendio ! com>
Date:       2006-11-28 13:53:33
Message-ID: Pine.LNX.4.62.0611281452290.27959 () master ! birnet ! private
[Download RAW message or body]

Hey all,

this is a proposal for allowing pluggable widget types and implementations,
assorted bug report: http://bugzilla.gnome.org/show_bug.cgi?id=356864

Platform and desktop customization needs, especially in the embedded market
go far beyond the themability support Gtk+ currently offers.
E.g. for touchscreens, special input methods (hand writing recognition or
virtual keyboards) need to be implemented, and sometimes complete widgets
or dialogs of stock Gtk+ have to be replaced by customized implementations.

It is already possible in Gtk+ to heavily customize specific application 
widgets or reimplement normal Gtk+ dialogs and widgets. What's left is a
mechanism in Gtk+ that allowes the stock widgets that Gtk+ usually creates,
to be exchanged for customized implementations.

That is, it needs to be possible to reimplement Gtk+'s file selector widget
and then have a simple way to inform Gtk+ to always use the custom 
file selector reimplementaiton instead of a stock GtkFileSelection for all
programs based on Gtk+.
For this to work, a widget or dialog reimplementation and substitution of
course needs to conform to the interfaces (by implementing those) which
are exposed by the stock components shipped with Gtk+.

Therefore, it'd be best to define future Gtk+ dialog APIs (and other
composite APIs) only in terms of interfaces and not widget type
implementations.

Since the interfaces of current stock Gtk+ dialogs are defined in terms of 
widget type implementations, the only way to ensure that such an interface
is implemented is by requiring derivation for a pluggable widget type.

Thus, a sample API for pluggable dialog types could look like this:

   void gtk_file_selector_appoint_type (GType gtkfileselector_derived_type);

   typedef struct _GtkPrinterSelectionInterface GtkPrinterSelectionInterface;
   void gtk_printer_selection_appoint_type (GType iface_implementation_type);

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.

The gtk_*_appoint_type() functions ensure that:
   g_type_is_a (gtkfileselector_derived_type, GTK_TYPE_FILE_SELECTOR) == 1
   /* GTK_TYPE_FILE_SELECTOR is a GtkWidget type */
and:
   g_type_is_a (iface_implementation_type, GTK_TYPE_PRINTER_SELECTION) == 1
   /* GTK_TYPE_PRINTER_SELECTION is an interface type */


This could conceivably be extended to plain widget types, as long as 
constructors are used for creation. For example imagine:

   void gtk_label_appoint_type (GType gtklabel_derived_type);

This could cause gtk_label_new() to create an instance of
gtklabel_derived_type, while g_object_new (GTK_TYPE_LABEL, NULL) still
creates an ordinary stock Gtk+ label.
However this will only make sense if internally to Gtk+, widgets are
created with gtk_*_new() constructur calls, and not g_object_new()
variants.

---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]