Re: GTK+ at the UX Hackfest

[Carlos Garnacho <carlosg gnome org>]

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.

If this isn't really expressive, IMHO we should either find a way to
have all that the necessary information transfered to the engine so it
knows what to do without peeping outside its scope, or just have a
single gtk_paint_widget (widget*,x,y,width,height) call so everything is
in the theme engine scope :P (yes that's crack)

In the case where the widget might want to do something completely
different as you say, we're already screwed by API (theme engines never
get the whole picture). Ignoring such information would be fine though,
it would look pretty much like we're already used to.

> 
> If two buttons are supposed to be connected because of some interaction
> design, then this should be reflected in a widget explicitly designed to
> cater for that situation.

Yes, there should be an specific widget, and I think it should provide
the guidelines for its styling, but I don't think it should be fully
responsible of it.

Besides, this wouldn't help in the situation where you want similar
widgets to actually look similar. As an example, how many failed
attempts have there been about making a popup calendar widget that
looked like GtkComboBoxEntry on certain themes? Right now, widgets in
that situation need to become popular first, and then have special
checks added to popular theme engines to get an uniform look, that's
rarely happening outside GTK+ widget set.

Cheers,
  Carlos