Re: [Usability] GTK+ at the UX Hackfest

[Thomas Wood <thos gnome org>]

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 <fargiolas 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