Re: Pluggable widget types and implementations

[Tristan Van Berkom <tvb gnome org>]

On Fri, 2006-12-08 at 14:36 +0000, Damon Chaplin wrote:
> On Fri, 2006-12-08 at 13:13 +0100, Tim Janik wrote: 
> > On Fri, 1 Dec 2006, Damon Chaplin wrote:
> > 
> > > On Tue, 2006-11-28 at 14:53 +0100, Tim Janik wrote:
> > >> 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
> > >
> > > How about a sort of widget/object factory?
> > >
> > > So you'd set the default implementation for a type:
> > >  gtk_object_factory_set_default_implementation (factory,
> > >                                                 GTK_TYPE_LABEL,
> > >                                                 MY_CUSTOM_LABEL_TYPE);
> > >
> > > And then in the widget/object xxx_new() functions instead of calling
> > > g_object_new() they call:
> > >  gtk_object_factory_create (factory, GTK_TYPE_LABEL, ...);
> > 
> > that sounds much like the alternative GFactory i suggested in 
> > another reply:
> >    http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00133.html
> 
> Yes, I missed half of the discussion somehow.
> 
> 
> > > Applications could then use different sets of widgets for different
> > > parts of the interface, just by switching the default factory:
> > >  gtk_set_default_object_factory (factory);
> > 
> > the only differences i see are that you didn't introduce the factory at 
> > GLib level, and that you seem to advocate multiple factories.
> > i'm not quite sure why though, can you give more concrete examples on
> > why i would want to switch factories at all?
> 
> I don't have any specific examples. I just thought using a factory was a
> more flexible approach - better than adding XXX_appoint_type() functions
> for each widget.

Would there be anything wrong with using the regular way of referring
to stock types in the same way we refer to stock icons/stock images
(and potentially stock cursors) ?

i.e. 
gtk_stock_appoint_type ("file-chooser", 
                         MYLIB_TYPE_SEXY_FILECHOOSER);

Using a const gchar * identifier might save us some ambiguity, it would
also purposefully break the possibility of an application expecting
to have an instance of GTK_TYPE_FOO, but unexpectedly getting a
GTK_TYPE_BAR instead, if the code only asked for a "foo-widget", then
it would be fair to return a dynamic type.

Cheers,
                   -Tristan