Re: WONTFIX-ing Pluggable Widgets Types

[Behdad Esfahbod <behdad behdad org>]

One thing I liked about the proposal that is still useful: appointing
default implementation for interfaces.  That will do the bit for things
like filechooser.

behdad


On Mon, 2007-04-02 at 09:41 -0400, Tim Janik wrote:
> hi all.
> 
> some weeks ago i posted two proposals for pluggable widget implementations:
>      http://bugzilla.gnome.org/show_bug.cgi?id=356864
>      http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00125.html
>      http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00073.html
> 
> i've had lots of different discussions with various people since, i'll 
> summarize the pros and cons in the following list:
> + pluggable widget types will allow vendor libraries to customize widgets
>    used by applications or other libraries.
> - customization of widget types will only work for an estimated 50% of the
>    desired cases. namely applications using g_object_new (GTK_TYPE) or
>    applications deriving from GTK_TYPE widgets will not be properly
>    customized.
> - we cannot generically allow "plugging" of base widget types that apps
>    derive from. significant alterations of base classes would simply break
>    too much compatibility in most cases. also see:
>      http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00098.html
> - pluggable widget types as proposed won't be able to fullfil the needs of
>    theme implementors (it was requested that we have a "vendor-only use"
>    disclaimer in the docs).
> - the bugzilla comments and the mailing list threads have shown that the very
>    concept of plugging widget types isn't easily understood. so it's probably
>    likely to be misused once it's introduced.
> 
> as a consequence, i now think that it's probably better to WONTFIX pluggable
> widget types for upstream.
> 
> for vendors that still want to customize widget property defaults or
> dialog behavior (the two main use cases for pluggable widget types we 
> could identify), i have these recommendations:
> 
> 1) customize widget properties (mostly defaults):
>     wait for completion of
>       http://bugzilla.gnome.org/show_bug.cgi?id=425324
>     then patch your gtk+ version to override gtk_widget_real_constructed()
>     to do any customization depending on the widget type.
> 
> 2) to customize widget behavior (please reconsider if this is really necessary
>     and couldn't be solved by an upstream patch instead):
>     apply a one-liner patch to your glib version and implement class specific
>     customization in vendor_customize_object_class():
>  	diff -Nup glib/gobject/gtype.c.orig glib/gobject/gtype.c
>  	--- glib/gobject/gtype.c        (revision 5438)
>  	+++ glib/gobject/gtype.c        (working copy)
>  	@@ -2391,6 +2391,7 @@ g_type_class_ref (GType type)
>  	        }
> 
>  	       type_class_init_Wm (node, pclass);
>  	+      vendor_customize_object_class (node->data->class.class);
>  	     }
>  	   G_WRITE_UNLOCK (&type_rw_lock);
> 
> ---
> ciaoTJ
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759