|
Frankly Thomas has given the best opinion on this. The idea behind the widget set should be to provide the MINIMAL REQUIRED functionality to address the mundane job of programming you own interface. HOWEVER, IMHO, if you want the library to do everything for you, then it will become bloated (frankly I'm already loosing track off all the the new widgets). I'm sure if you ask around especially in this list, you can drum up thousands of widget requests (where individual programmers will want specif widget most of which will be only STYLISTICALLY different). Whatever the theme engine can not handle, you can certainly override the expose event, motion / button press events to create your own derived widget. IE. Use a button box, override methods with your own specific methods. You can use the same process of adding and deleting buttons, etc.... but draw them yourself in the exact way you want.
> Subject: Re: GTK+ at the UX Hackfest > From: thos gnome org > To: carlosg gnome org > Date: Wed, 3 Mar 2010 11:45:33 +0000 > CC: jimmac novell com; usability gnome org; gtk-devel-list gnome org; wwalker gnome org; bratsche gnome org; hylkebons gmail com > > 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. > > 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. > > Regards, > > Thomas > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list |