Re: Pluggable widgets II

[Paul Pogonyshev <pogonyshev gmx net>]

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