WONTFIX-ing Pluggable Widgets Types
- From: Tim Janik <timj imendio com>
- To: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: WONTFIX-ing Pluggable Widgets Types
- Date: Mon, 2 Apr 2007 15:41:21 +0200 (CEST)
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]