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. 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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list