Re: g_atomic_pointer*
On Mon, 2010-03-01 at 10:35 +, James Morris wrote: Hi, I need to use an atomic pointer for my app. The documentation for the glib atomic operations is not exactly helpful. Anyway, I wrote a test program: g_atomic_pointer_set(myptr, str); char* p = g_atomic_pointer_get(myptr); (...) to understand what was meant to be used as the parameters. Anyway, the output of this does not look at all atomic: (not that i'm any expert) ((void) (*(myptr) = (str))); char* p = ((gpointer)*(myptr)); This is on a x86_64, running Gentoo, glib-2.20.5. I don't know if I've got the idea right for how these functions are supposed to be used. Any ideas? This should be ok in your case, it may expand to something else on other platforms though. Cheers -Tim ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-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 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. 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, 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. 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
On Tue, 2010-03-02 at 23:55 +0100, Filippo Argiolas wrote: On Tue, Mar 2, 2010 at 1:22 PM, Bastien Nocera had...@hadess.net wrote: On Tue, 2010-03-02 at 13:06 +0100, Filippo Argiolas wrote: On Mon, Mar 1, 2010 at 3:57 PM, Bastien Nocera had...@hadess.net 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: [Usability] GTK+ at the UX Hackfest
On Wed, 2010-03-03 at 15:48 +0800, Li Yuan wrote: On Tue, 2010-03-02 at 12:27 +, Bastien Nocera wrote: On Tue, 2010-03-02 at 12:22 +0800, Li Yuan wrote: 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. Right, it seems the discussion we had with Willie was with outdated or incorrect data, so let's step back and look at the original problem again. Ah, sorry I didn't say it clearly. I didn't mean there is no problem to unload the modules. I meant we could use the gnome_accessibility_module_shutdown functions to disable accessibility. I was actually talking about the instant-load for the modules when the XSettings change. We'd like to be able to enable/disable a11y in applications without a session restart, and, if possible, when deactivated, that the modules are unloaded and all a11y related functionality is torn down. As the previous mail I sent, it is possible to enable accessibility without session restart. For disable, it depends on how we do it. It is possible to deregister the applications from registryd in gnome_accessibility_module_shutdown function, but unloaded the modules will cause applications crash. It would be nice if you could test that instant-on a11y works as expected (module loading, application registering) and let us know whether it works. Shutting down is always going to be a bit more complicated, but the overhead of the leaks should be small enough that it wouldn't matter for the short term. Do you want to look into that? Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Usability] GTK+ at the UX Hackfest
On Wed, 2010-03-03 at 15:57 +0800, Li Yuan wrote: On Tue, 2010-03-02 at 12:27 +, Bastien Nocera wrote: What is missing for this to work? Can we remove the you need to restart your session from the a11y capplet in the control-center? I just remember that the bonobo activation code has been removed from atk-bridge. So the code probably needs to be added back before the modification in control-center. What's the target version for this change? My guess is 3.0. It's already too late for GNOME 2.30, and 3.0 gives us the ability to break things. If one particular application doesn't work well with the instant-on changes, we can always ask for them to fix it. Changing the behaviour mid-way a stable release is asking for trouble. 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 Wed, Mar 3, 2010 at 12:58 PM, Bastien Nocera had...@hadess.net 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 Wed, Mar 3, 2010 at 1:14 PM, Filippo Argiolas fargio...@gnome.org wrote: On Wed, Mar 3, 2010 at 12:58 PM, Bastien Nocera had...@hadess.net 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
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 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
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 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. 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: [Usability] GTK+ at the UX Hackfest
On Tue, 2010-03-02 at 12:27 +, Bastien Nocera wrote: What is missing for this to work? Can we remove the you need to restart your session from the a11y capplet in the control-center? I just remember that the bonobo activation code has been removed from atk-bridge. So the code probably needs to be added back before the modification in control-center. What's the target version for this change? Li ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
