On Wed, 2010-03-03 at 14:49 +0100, Carlos Garnacho wrote: > Hi :), > > On mié, 2010-03-03 at 11:45 +0000, Thomas Wood wrote: > > On Wed, 2010-03-03 at 12:20 +0100, Carlos Garnacho wrote: > > > Hi!, > > > > > > On mié, 2010-03-03 at 00:03 +0100, Filippo Argiolas wrote: > > > > On Tue, Mar 2, 2010 at 11:55 PM, Filippo Argiolas <fargio...@gnome.org> > > > > wrote: > > > > > > > > [cut] > > > > > > > > > Well it's not actually the radio functionality that I really care, > > > > > that's easily implementable. It's more the custom container that can > > > > > be themed to visually merge together several buttons. Once that's > > > > > done, the buttons could behave like simple buttons (probably useless), > > > > > toggle buttons or radio buttons. They would be just the usual buttons > > > > > into a special container probably. > > > > > > > > Look at Carlos post about theming hackfest too[1]. Point 3 really > > > > seems to be exactly what I'm talking about. > > > > > > > > 1. http://blogs.gnome.org/carlosg/2009/02/20/dublin-theming-hackfest/ > > > > > > The idea there is that current widgets/containers would be able to tell > > > theme engines how do painted items visually connect each other. There > > > would be no need for special containers or buttons, nor hacks in theme > > > engines such as peeping into the parent widget GType. > > > > > > I'm really not sure this is a good idea; it's really not expressive > > enough to just say "this button is somehow related to this one" and let > > themes decide what to do with it. Some themes might ignore it, some > > themes might do what you expect and some themes may want to do something > > completely different. > > But we still have a painting API that's fully oriented to painting > individual elements, and what we aren't advertising is that these calls > aren't stateful in any way, you can call the very same function with the > very same parameters in different widgets' expose handlers and get > different results.
I think the "primitives" API is something we need to move away from. It is a nice idea, but just doesn't work out in practice. Theme authors end up special casing every widget available anyway in a rather hacky work-around fashion because of the constraints imposed by the "elements" method. Owen already wrote his thoughts on a future theming API here: http://mail.gnome.org/archives/gnome-themes-list/2008-July/msg00017.html As someone being involved in gtk-themes for a long time, I have come to the same conclusion. This is what I am working on for Monet. In terms of default theme, I am more than happy to implement Jakub/Hylke's mockups as the default theme for Monet. Regards, Thomas _______________________________________________ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
