Re: WONTFIX-ing Pluggable Widgets Types

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.


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

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

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