Re: GTK+ at the UX Hackfest
On 03/02/2010 05:55 PM, Filippo Argiolas wrote: > Anyway, I still think that breadcrumb could be a subclass of this > "button group" (a subclass widget *is* more complicated than the > widget it subclasses), but maybe I didn't get the whole breadcrumb > thing. Just because a breadcrumb may be implemented as *using* a button group doesn't mean it's a subclass of it. A different looking implementation may use a totally different configuration. behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
On Wed, 2010-03-03 at 14:49 +0100, Carlos Garnacho wrote: > Hi :), > > On mié, 2010-03-03 at 11:45 +, 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 > > > > 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
Mathias made the patch (http://bugzilla-attachments.gnome.org/attachment.cgi?id=118981 ) to make at-spi support XSettings. >From a11y side, gail and atk-bridge/atk-adaptor, as GTK+ modules, should be able to be loaded at any time. If there is no registry daemon running, for CORBA version, at-spi-registryd will be started through Bonobo activation (atk-bridge does this job); for D-Bus version, at-spi2-registryd should be started through D-Bus activation (atk-adaptor does this job). There are also gnome_accessibility_module_shutdown functions for these A11Y modules. Maybe we need a unified way to shutdown GTK+ modules. Li On Mon, 2010-03-01 at 17:38 +0100, Piñeiro wrote: > From: Cosimo Cecchi > > > On Mon, 2010-03-01 at 16:44 +0100, Piñeiro wrote: > > > >> In the gtk side, I don't know much about the XSettings, but I suppose > >> that you are talking more general, and XSetting will manage all the > >> gtk modules to be loaded (engines, and so on). So XSettings would have > >> the lists of modules instead of the envvar, and inform to the > >> applications that this setting has changed. In this case is just > >> load/unload the a11y modules as any other gtk modules. > > > > AFAIK GTK+ already reads the XSettings variable and loads modules > > accordingly in gtk_init(). The filling of that property is currently > > done by gnome-settings-daemon. > > Yes, you are right, I have just made a quick search, thanks. > > Probably people like Mathias Clasen, Li Yuan and Willie Walker knows > more about xsettings and a11y relation. After another quick search on > the bugzilla, I found some interesting (and resolved) bugs about this > issue: > > https://bugzilla.gnome.org/show_bug.cgi?id=535827 > https://bugzilla.gnome.org/show_bug.cgi?id=565110 > https://bugzilla.gnome.org/show_bug.cgi?id=563943 > > === > API (apinhe...@igalia.com) > ___ > gnome-accessibility-list mailing list > gnome-accessibility-l...@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: GTK+ at the UX Hackfest
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. EMAILING FOR THE GREATER GOOD Join me > Subject: Re: GTK+ at the UX Hackfest > From: t...@gnome.org > To: carl...@gnome.org > Date: Wed, 3 Mar 2010 11:45:33 + > CC: jim...@novell.com; usabil...@gnome.org; gtk-devel-list@gnome.org; > wwal...@gnome.org; brats...@gnome.org; hylkeb...@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 > > > 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
Hi :), On mié, 2010-03-03 at 11:45 +, 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 > > > 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
Re: GTK+ at the UX Hackfest
On Wed, Mar 3, 2010 at 1:14 PM, Filippo Argiolas wrote: > On Wed, Mar 3, 2010 at 12:58 PM, Bastien Nocera wrote: >> Right, so it's a theming change, and has nothing to do with the widgets >> themselves. > [CUT] >> Again, you made it sound like you wanted a new widget when you actually >> wanted a group of buttons to *look* like they were related. > > Right, my fault, reading what I wrote in the first mail I think I > wasn't clear at all. Sorry. > >>> > My guess is that you could probably get this widget added to GTK+, as >>> > long as you give a formal explanation as to why you're not using a radio >>> > button for this. >>> >>> Well, the reason is simple, sexiness. Would you really put radio >>> buttons into a toolbar? >> >> "Sexiness" isn't a good enough reason. Why do you use that widget in the >> first place? Why not put radio buttons instead? (And this is a >> rhetorical question for this list, as I mentioned, put this in bugzilla) > > Ok, I'll open a bug to track this proposal. Bug filed: https://bugzilla.gnome.org/show_bug.cgi?id=611695 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
On Wed, Mar 3, 2010 at 12:58 PM, Bastien Nocera wrote: > Right, so it's a theming change, and has nothing to do with the widgets > themselves. [CUT] > Again, you made it sound like you wanted a new widget when you actually > wanted a group of buttons to *look* like they were related. Right, my fault, reading what I wrote in the first mail I think I wasn't clear at all. Sorry. >> > My guess is that you could probably get this widget added to GTK+, as >> > long as you give a formal explanation as to why you're not using a radio >> > button for this. >> >> Well, the reason is simple, sexiness. Would you really put radio >> buttons into a toolbar? > > "Sexiness" isn't a good enough reason. Why do you use that widget in the > first place? Why not put radio buttons instead? (And this is a > rhetorical question for this list, as I mentioned, put this in bugzilla) Ok, I'll open a bug to track this proposal. Filippo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
On Tue, 2010-03-02 at 23:55 +0100, Filippo Argiolas wrote:
> On Tue, Mar 2, 2010 at 1:22 PM, Bastien Nocera wrote:
> > On Tue, 2010-03-02 at 13:06 +0100, Filippo Argiolas wrote:
> >> On Mon, Mar 1, 2010 at 3:57 PM, Bastien Nocera wrote:
> >> > Heya,
> >> In Cheese we'd like to have something that I'd call ButtonGroup,
> >> ToggleButtonGroup or RadioButtonGroup, something like a breadcrumb
> >> (see e.g. screenshots at http://audidude.com/?p=27) but without the
> >> breadcrumb logic. Maybe the breadcrumb could be a subclass of
> >> this/these widget/widgets.
> >
> > Breadcrumb is probably more complicated than any of those, to be fair.
>
> To be fair I don't think you completely got what I was trying to say.
> I cited the breadcrumb because it's usually visually styled as a group
> of buttons (that behave like radios plus some more complicated logic)
> grouped together into a "single big button" that contains several
> ones. If you look at the screenshots in that link I think it's pretty
> clear, I'd like a way to "visually merge" together several buttons
> into a grouping container. Look at this mockup too, it should make it
> clear enough:
> http://people.gnome.org/~fargiolas/toggle-button-mockup.png
>
> Anyway, I still think that breadcrumb could be a subclass of this
> "button group" (a subclass widget *is* more complicated than the
> widget it subclasses), but maybe I didn't get the whole breadcrumb
> thing.
Right, so it's a theming change, and has nothing to do with the widgets
themselves.
> >> We would use it in the toolbar in the "mode selector"
> >> (gnome.org/~fargiolas/togglegroup.png), currently we use three toggle
> >> buttons related to three radio actions but it would be great to style
> >> them as a single widget.
> >> Anyone else would like a widget like this?
> >
> > Seems to me that this widget would be a sub-class of a RadioButton. It's
> > a toggle button that's part of a RadioButtonGroup.
>
> 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.
Again, you made it sound like you wanted a new widget when you actually
wanted a group of buttons to *look* like they were related.
> > My guess is that you could probably get this widget added to GTK+, as
> > long as you give a formal explanation as to why you're not using a radio
> > button for this.
>
> Well, the reason is simple, sexiness. Would you really put radio
> buttons into a toolbar?
"Sexiness" isn't a good enough reason. Why do you use that widget in the
first place? Why not put radio buttons instead? (And this is a
rhetorical question for this list, as I mentioned, put this in bugzilla)
The point is that we want to have a trace with explanations as to why
widgets were added. My 2 last contributions in that space were the
volume button ("A lot of multimedia applications use copy/pasted code to
that effect, it works as a toolbar item, it provides consistent
behaviour and look across applications"), and a spinner widget (for
pretty much the same reasons).
At the end of the day, it could be a theming option you're talking
about, or a new widget (see the discussion between Carlos and Thomas).
For the latter, you'd need more than "it looks good".
> Hope I was more clear this time,
> Cheers,
>
> Filippo
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
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 > > 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
Re: GTK+ at the UX Hackfest
Hi!, On mié, 2010-03-03 at 00:03 +0100, Filippo Argiolas wrote: > On Tue, Mar 2, 2010 at 11:55 PM, Filippo Argiolas 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. Cheers, Carlos > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
On Wed, Mar 3, 2010 at 5:23 AM, Christian Hergert wrote: > On Mar 2, 2010, at 2:55 PM, Filippo Argiolas wrote: >> http://people.gnome.org/~fargiolas/toggle-button-mockup.png > > I don't want to detract from your conversation, but in case you haven't > written up code for that toggle button mockup, I wrote one last year (in > python, c, and c#). > > http://audidude.com/?p=61 > http://github.com/chergert/custom-gtk-widgets/tree/master/gtkmodebutton Hi Christian, thanks for the links. I didn't write any code yet because I'm still looking for the proper way to do it and I'd like to use something integrated in gtk+ since the beginning. About your widget, I looked into it some time ago. I think it is basically an hack, a neat and sexy hack, don't get me wrong, but still an hack. Particularly, it doesn't handle focus nor keyboard navigation and the selected button doesn't look depressed as buttons usually do but is shaded with the "selected" color. Furthermore it breaks with some theme. I could try to implement all of those things using your widget as a base but I don't really think that would be the best way. We already have buttons that work fine, we just need a way to group them and tell the engine to style it properly. We have widgets that work like that, GtkComboBoxEntry e.g. uses a simple button for the drop down arrow button and it's the theme engine that styles it properly to have a straight edge where it connects with the entry. Cheers, Filippo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
On Mar 2, 2010, at 2:55 PM, Filippo Argiolas wrote: To be fair I don't think you completely got what I was trying to say. I cited the breadcrumb because it's usually visually styled as a group of buttons (that behave like radios plus some more complicated logic) grouped together into a "single big button" that contains several ones. If you look at the screenshots in that link I think it's pretty clear, I'd like a way to "visually merge" together several buttons into a grouping container. Look at this mockup too, it should make it clear enough: http://people.gnome.org/~fargiolas/toggle-button-mockup.png I don't want to detract from your conversation, but in case you haven't written up code for that toggle button mockup, I wrote one last year (in python, c, and c#). http://audidude.com/?p=61 http://github.com/chergert/custom-gtk-widgets/tree/master/gtkmodebutton Cheers, -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
On Tue, Mar 2, 2010 at 11:55 PM, Filippo Argiolas 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/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
On Tue, Mar 2, 2010 at 1:22 PM, Bastien Nocera wrote: > On Tue, 2010-03-02 at 13:06 +0100, Filippo Argiolas wrote: >> On Mon, Mar 1, 2010 at 3:57 PM, Bastien Nocera wrote: >> > Heya, >> In Cheese we'd like to have something that I'd call ButtonGroup, >> ToggleButtonGroup or RadioButtonGroup, something like a breadcrumb >> (see e.g. screenshots at http://audidude.com/?p=27) but without the >> breadcrumb logic. Maybe the breadcrumb could be a subclass of >> this/these widget/widgets. > > Breadcrumb is probably more complicated than any of those, to be fair. To be fair I don't think you completely got what I was trying to say. I cited the breadcrumb because it's usually visually styled as a group of buttons (that behave like radios plus some more complicated logic) grouped together into a "single big button" that contains several ones. If you look at the screenshots in that link I think it's pretty clear, I'd like a way to "visually merge" together several buttons into a grouping container. Look at this mockup too, it should make it clear enough: http://people.gnome.org/~fargiolas/toggle-button-mockup.png Anyway, I still think that breadcrumb could be a subclass of this "button group" (a subclass widget *is* more complicated than the widget it subclasses), but maybe I didn't get the whole breadcrumb thing. >> We would use it in the toolbar in the "mode selector" >> (gnome.org/~fargiolas/togglegroup.png), currently we use three toggle >> buttons related to three radio actions but it would be great to style >> them as a single widget. >> Anyone else would like a widget like this? > > Seems to me that this widget would be a sub-class of a RadioButton. It's > a toggle button that's part of a RadioButtonGroup. 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. > My guess is that you could probably get this widget added to GTK+, as > long as you give a formal explanation as to why you're not using a radio > button for this. Well, the reason is simple, sexiness. Would you really put radio buttons into a toolbar? Hope I was more clear this time, Cheers, Filippo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Theming migration proposal [Was: Re: GTK+ at the UX Hackfest]
Hi!, On lun, 2010-03-01 at 14:57 +, Bastien Nocera wrote: > Theming > --- > > Just a couple of opened questions: > - GTK+ 3.0 theme. How final are the widget set used in the various > mockups that were posted during the UX hackfest? Cody mentioned that > this is something he might be able to allocate some time for. Thomas > Wood might be able to help (though he was non-committal when we > mentioned it during the hackfest) Recently I've started working again on refining the ideas that sprung from the Dublin theming hackfest. I've written down the proposal in: http://live.gnome.org/CarlosGarnacho/ThemingProposal The main benefit I see in this approach is that it would allow incremental development. After the main infrastructure and the new theming API are in place, any missing items (newer rc files syntax, use all api features in widgets, updating engines) could be done pretty much independently. Although there's not much code put together yet, a lot can be taken from what was started back then [1], so I'm quite positive that I may have something tangible within weeks. Cheers, Carlos [1] http://github.com/garnacho/gtk/tree/style-context ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
On Tue, 2010-03-02 at 13:06 +0100, Filippo Argiolas wrote: > On Mon, Mar 1, 2010 at 3:57 PM, Bastien Nocera wrote: > > Heya, > Hey, > > > Widgets > > --- > > > > Having often used widgets in GTK+ means that we reduce differences in > > appearance and behaviour between applications and make applications > > easier to maintain. > > > > If the APIs are carefully thought of, usability and design changes can > > be made without touching the applications. > > > > A couple of widgets were mentioned: > > - a sidebar widget (which I never followed-up on): > > https://bugzilla.gnome.org/show_bug.cgi?id=307044 > > - a breadcrumb navigation widget (which could be used in nautilus, the > > file chooser and yelp, for example) > > No bugs filed, Cody will be working on filing a bug, and start > > discussions about the API soon > > - Segmented bar? It's used in Rhythmbox, Banshee, the Ubuntu installer > > and could probably be used in others > > There's a C version in Rhythmbox now: > > https://bugzilla.gnome.org/show_bug.cgi?id=558576 > > - Others? > > In Cheese we'd like to have something that I'd call ButtonGroup, > ToggleButtonGroup or RadioButtonGroup, something like a breadcrumb > (see e.g. screenshots at http://audidude.com/?p=27) but without the > breadcrumb logic. Maybe the breadcrumb could be a subclass of > this/these widget/widgets. Breadcrumb is probably more complicated than any of those, to be fair. > We would use it in the toolbar in the "mode selector" > (gnome.org/~fargiolas/togglegroup.png), currently we use three toggle > buttons related to three radio actions but it would be great to style > them as a single widget. > Anyone else would like a widget like this? Seems to me that this widget would be a sub-class of a RadioButton. It's a toggle button that's part of a RadioButtonGroup. My guess is that you could probably get this widget added to GTK+, as long as you give a formal explanation as to why you're not using a radio button for this. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
On Mon, 2010-03-01 at 17:38 +0100, Piñeiro wrote: > From: Cosimo Cecchi > > > On Mon, 2010-03-01 at 16:44 +0100, Piñeiro wrote: > > > >> In the gtk side, I don't know much about the XSettings, but I suppose > >> that you are talking more general, and XSetting will manage all the > >> gtk modules to be loaded (engines, and so on). So XSettings would have > >> the lists of modules instead of the envvar, and inform to the > >> applications that this setting has changed. In this case is just > >> load/unload the a11y modules as any other gtk modules. > > > > AFAIK GTK+ already reads the XSettings variable and loads modules > > accordingly in gtk_init(). The filling of that property is currently > > done by gnome-settings-daemon. > > Yes, you are right, I have just made a quick search, thanks. > > Probably people like Mathias Clasen, Li Yuan and Willie Walker knows > more about xsettings and a11y relation. After another quick search on > the bugzilla, I found some interesting (and resolved) bugs about this > issue: I should have mentioned that it's Willie I was talking to last week, and that brought up this potential problem. Matthias told me that the XSettings are already instant-apply/instant-load, so that's not the problem for an instant-apply a11y, registration is more likely the problem. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
On Mon, Mar 1, 2010 at 3:57 PM, Bastien Nocera wrote: > Heya, Hey, > Widgets > --- > > Having often used widgets in GTK+ means that we reduce differences in > appearance and behaviour between applications and make applications > easier to maintain. > > If the APIs are carefully thought of, usability and design changes can > be made without touching the applications. > > A couple of widgets were mentioned: > - a sidebar widget (which I never followed-up on): > https://bugzilla.gnome.org/show_bug.cgi?id=307044 > - a breadcrumb navigation widget (which could be used in nautilus, the > file chooser and yelp, for example) > No bugs filed, Cody will be working on filing a bug, and start > discussions about the API soon > - Segmented bar? It's used in Rhythmbox, Banshee, the Ubuntu installer > and could probably be used in others > There's a C version in Rhythmbox now: > https://bugzilla.gnome.org/show_bug.cgi?id=558576 > - Others? In Cheese we'd like to have something that I'd call ButtonGroup, ToggleButtonGroup or RadioButtonGroup, something like a breadcrumb (see e.g. screenshots at http://audidude.com/?p=27) but without the breadcrumb logic. Maybe the breadcrumb could be a subclass of this/these widget/widgets. We would use it in the toolbar in the "mode selector" (gnome.org/~fargiolas/togglegroup.png), currently we use three toggle buttons related to three radio actions but it would be great to style them as a single widget. Anyone else would like a widget like this? Ciao, Filippo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
From: Cosimo Cecchi > On Mon, 2010-03-01 at 16:44 +0100, Piñeiro wrote: > >> In the gtk side, I don't know much about the XSettings, but I suppose >> that you are talking more general, and XSetting will manage all the >> gtk modules to be loaded (engines, and so on). So XSettings would have >> the lists of modules instead of the envvar, and inform to the >> applications that this setting has changed. In this case is just >> load/unload the a11y modules as any other gtk modules. > > AFAIK GTK+ already reads the XSettings variable and loads modules > accordingly in gtk_init(). The filling of that property is currently > done by gnome-settings-daemon. Yes, you are right, I have just made a quick search, thanks. Probably people like Mathias Clasen, Li Yuan and Willie Walker knows more about xsettings and a11y relation. After another quick search on the bugzilla, I found some interesting (and resolved) bugs about this issue: https://bugzilla.gnome.org/show_bug.cgi?id=535827 https://bugzilla.gnome.org/show_bug.cgi?id=565110 https://bugzilla.gnome.org/show_bug.cgi?id=563943 === API (apinhe...@igalia.com) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
On Mon, 2010-03-01 at 16:44 +0100, Piñeiro wrote: > In the gtk side, I don't know much about the XSettings, but I suppose > that you are talking more general, and XSetting will manage all the > gtk modules to be loaded (engines, and so on). So XSettings would have > the lists of modules instead of the envvar, and inform to the > applications that this setting has changed. In this case is just > load/unload the a11y modules as any other gtk modules. AFAIK GTK+ already reads the XSettings variable and loads modules accordingly in gtk_init(). The filling of that property is currently done by gnome-settings-daemon. Cheers, Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ at the UX Hackfest
From: Bastien Nocera CCing gnome-accessibility list, as probably I will forgot several things. > - a11y instant-on (if not instant-off) > a11y is enabled in applications when the XSettings mention that the GTK+ > modules should be loaded. We could make GTK+ programs instant-apply the > XSettings (what applications would be breaking? Could we whitelist a11y > to be the only one auto-loaded? Can we make the change for GTK+ 3.0?) > > The other problem is that application need to initialise themselves, and > register with the at-spi bus to appear in things like screen readers. > > Could somebody with more knowledge on the subject tell me what changes > would be necessary for a11y to become instant-apply? The initalization can be done at any moment (and as you said, made by the application themselves). Right now gtk apps require to load gail and atk-bridge modules, so they just need to load this modules using gmodule, and then call the method gtk_module_init (although the method gnome_accessibility_module_init is also provided). At this moment, to made that more easy, this is done during the gtk_init, as it load the gtk modules reading the envar GTK_MODULES (as far as I undertand, the idea now is avoid that and start to use XSettings). About the unload, there are also a method gnome_accessibility_module_shutdown (but not gtk_module_shutdown one), so it would be just call this method and unload the modules. So in theory, no changes should be required from the a11y modules, except, perhaps, add a gtk_module_shutdown method, in order to be more general. In the gtk side, I don't know much about the XSettings, but I suppose that you are talking more general, and XSetting will manage all the gtk modules to be loaded (engines, and so on). So XSettings would have the lists of modules instead of the envvar, and inform to the applications that this setting has changed. In this case is just load/unload the a11y modules as any other gtk modules. Anyway, there are some applications that made that in a custom way. The main example is firefox. As they have some custom a11y thingies, they override this procedure (ie loading by hand the atk bridge). So if firefox wants to use the XSettings solution he would require to rewrite that part, and from the gtk side, it should allow a process to be overriden. Firefox created a log of headaches in this aspect. More information and several cross-bugs here [1] Other issue is that the at-spi daemon (corba or dbus) must be running before the application load the modules (one part of this a11y initialization from the application side is register on at-spi). This can be tricky on the first application that want to instant-on the a11y, and it would require to check if the daemon is running, and if not, execute that. The other module part are general (just load gtk modules when required) but this step requires specific code. BR [1] http://mail.gnome.org/archives/gnome-accessibility-list/2009-January/msg00030.html === API (apinhe...@igalia.com) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
