Benjamin Otte wrote: > Tim Janik <timj <at> imendio.com> writes: > > > > - How does this work for application derived types? > > > > > > e.g. if vino derives from GtkLabel to make a label which looks like > > > a clickable URL, then even if it is instantiated using > > > g_factory_create() a gtk theme module will not be able to replace > > > it given the fact it does not have access to the derived gtype > > > > a theme has many other means to affect widget look or behavior. > > it is not meant to appoint new widget types. or - if you have a > > use case for this, please elaborate. > > I just talked on IRC about this with Tim, and he made me repost the points of > our discussion here, so here they are: > > - This API is very powerful, but may result in weird behavior if it is not > clearly defined who is supposed to use these appointments. [...]
This is a good point. I'd suggest that all usage is left _exclusively_ to programmers of end-level applications and libraries that you must actively include in your application. I.e. it is improper if some library, e.g. a theme engine, appointed a type without your knowing of this, because it can break an application in an unpredictable way. On the other hand, it should be OK if you consciously use libmycoolwidgets and that library appoints custom types for some widgets---you know (at least should know) about this and can take this into account, if needed. In other words, it should be OK for a required library and the application itself to appoint types. It should be strictly forbidden for optional libraries (themes, etc.), because you can then know nothing in advance. Unlike this, platform- and theme-specific customization should restricted to styling the default widget implementations. It would be good if GLib could enforce such a restriction in some way. Paul _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list