WONTFIX-ing Pluggable Widgets Types



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



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