GNOME Bugzilla – Bug 356864
Allow pluggable widget types or implementations
Last modified: 2007-04-03 10:53:59 UTC
Gtk+ should allow customization of stock widgets and dialogs. It is already possible to heavily customize or reimplement normal Gtk+ dialogs and widgets. What's left is a mechanism in Gtk+ that allowes the stock widgets that Gtk+ usually creates, to be exchanged for customized implementations. For instance company Foo could implement the FooFileSelector and then should have a simple way to inform Gtk+ to always use FooFileSelector instead of stock GtkFileSelection for all programs that ship with FooDistro or run on FooDevices.
a proposal for pluggable types is being discussed on the list now: http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00125.html
I filed a similar proposal for PyGObject, see bug 383495 before knowing about this. Also see bug 373110. Glad I'm not the only one missing this feature :)
Created attachment 77986 [details] sample implementation beginnings and a test I post here a very simple implementation (coming along with a test.) It can and should be improved, I just want to show how it could look like. Compile with gcc -g `pkg-config --cflags --libs glib-2.0 gtk+-2.0` gobjectfactory.c -o gobjectfactory
*** Bug 373110 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Created an attachment (id=77986) [edit] > sample implementation beginnings and a test > > I post here a very simple implementation (coming along with a test.) It can > and should be improved, I just want to show how it could look like. > > Compile with > > gcc -g `pkg-config --cflags --libs glib-2.0 gtk+-2.0` gobjectfactory.c -o > gobjectfactory thanks. two comments about the patch: - i'd rather stick to the g_factory_* API described on the mailing list, - the wrapper type is better stored as GType qdata, that is thread-safe already and should also be fast enough.
I'm not subscribed to the mailing list, so a link to releveant messages in the archives would be appreciated. I could massage the patch if you wish, but please state it explicitly then. I don't want to accidentally duplicate work with you :)
(In reply to comment #6) > I'm not subscribed to the mailing list, so a link to releveant messages in the > archives would be appreciated. i'm referring to the thread from Comment #1: http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00125.html if you want to seriously be involved in glib or gtk+ development though (e.g. write and discuss patches), you're best off with joining the mailing list though. > I could massage the patch if you wish, but please state it explicitly then. I > don't want to accidentally duplicate work with you :) thanks, the implementation isn't particularly tricky here. this issue is more tricky in terms of API and backwards compatibility. so no, i don't actually need a patch from you for this report. your input on the mailing list thread is apprechiated though if you have any new things to say ;)
a revamped proposal is presented in a new thread: http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00073.html
Let me reiterate why I think appointable types must be left for use of application developers exclusively. Let's say there is type A in GTK+. And let's say a theme or vendor-specific code appoints type B (subclass of A) to customize it. Now there is some application. As long as it uses stock GTK+ widget A, everything is cool, because it gets replaced by GLib by B automatically. But suppose the application derived type C from A and used it instead. Application simply had no knowledget about type B in advance (because vendor Foo appoints type B, vendor Bar -- type X and vendor Baz is happy with GTK+ widget A and doesn't appoint anything.) Now, vendor customization is _lost_ for the application. Worse yet, if it uses its own type C along with A (with type B appointed for it), some widgets (B) will have vendor customization and some (C) will not, which will look silly and confusing to users. What can be done about it? I can see two options: * Live with it. I consider it a bad solution, because it invites vendors to implement half-working customizations (won't work in all applications) and programers to make tough lose-lose decision: either derive and accept that this will break some customizations at least on some platforms; or not derive in any case. * Declare derivation a no-no, because it can break something. I consider this a _very bad_ solution, because it goes completely contrary to OO programming paradigm. It is like declaring GTK+ to be perfect in absolutely all situations and that no derivation by application is ever needed. That is just arrogant if you ask me. Besides, it is common to derive custom widget types in language bindings, e.g. in PyGTK. * Require that type appointing is left _exclusively_ to end-application programmer to decide. This solves the outlined problem at the expense of some use cases (by vendors, themes, etc.). I consider it the best of the alternatives. Therefore, I think: * Vendors, themes and everything _optional_, i.e. something that can or can not be present for a working application, _must not_ use type appointing, because such appointing will be lost if an application uses not the type, but its descendant. * Application itself and the libraries it _requires_ are the only entities allowed to appoint types. (If I require type X that appoints CoolXWidget type for XWidget I know or at least should know that.) If a library appoints a type, it _must_ be mentioned in documentation and made public in case a user of the library decides to further subclass it.
(In reply to comment #11) > * Live with it. I consider it a bad solution, because it invites vendors to > implement half-working customizations (won't work in all applications) and > programers to make tough lose-lose decision: either derive and accept that this > will break some customizations at least on some platforms; or not derive in any > case. this is the only way that pluggable widget types can be added backwards compatibly to gtk at all. > * Declare derivation a no-no, because it can break something. this is not worth discussing, it's simply impossible given backwards compatibility. > * Require that type appointing is left _exclusively_ to end-application > programmer to decide. this is already the case, because applicaiton authors already get to choose which widgets their application uses by calling g_object_new(TARGET_TYPE). the idea behind appointing is for libraries to be able to customize widget types when the application authors calls something like gtk_label_new(). > * Vendors, themes and everything _optional_, i.e. something that can or can > not be present for a working application, _must not_ use type appointing, > because such appointing will be lost if an application uses not the type, > but its descendant. this is a known pitfall of the appointing, yes. if we add it, it'll definitely not work perfectly, because we can't exchange base types that applications derive from. > * Application itself and the libraries it _requires_ are the only entities > allowed to appoint types. as outlined above, applications already can do that. libraries (esp. vendor/platform specific libs, e.g. libgnomeui) cannot currently do that. enabling libraries is what plugging widget types is all about. > (If I require type X that appoints CoolXWidget type > for XWidget I know or at least should know that.) If a library appoints a > type, it _must_ be mentioned in documentation and made public in case a user > of the library decides to further subclass it. documentation doesn't fix the problem you outline above. the application author might not be aware of the appointing behavior a vendor lib or a future version of a required platform lib at the time of writing his application. as for the appointing behavior "made public", the last proposal includes functions to query appointing behavior and using g_object_new() it can always be bypassed.
> > * Require that type appointing is left _exclusively_ to end-application > > programmer to decide. > > this is already the case, because applicaiton authors already get to choose > which widgets their application uses by calling g_object_new(TARGET_TYPE). Not in all cases. If you create a compound widget (e.g. GtkComboBox or any standard dialog), all internal widgets will be of standard types and you have no way to alter that. That was my use case: to allow appointing types so that you can alter appearance/behaviour/whatever of the standard compound widgets.
closing pluggable widget types as WONTFIX for the reasons outlined on the mailing list: http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00010.html