Re: I have a problem
On Mon, May 30, 2011 at 11:02 AM, Benjamin Otte o...@gnome.org wrote: That said, let me get into how I think this whole interaction between designers and developers should work inside GTK. I envision the design process for new widgets or interactions to go something like this: 1) GNOME designers come up with an idea 2) GTK developers implement the idea 3) application developers and designers (both inside GNOME and ISVs) use it in their applications There's maybe a 1.5) GNOME ships a prototype application to test things in between. (Of course, this is not a top-down approach. Ideally the application developers provide feedback about how they think GTK should work to the GTK developers and the GTK developers I think this is a bit backwards. Your afterthought of 1.5 is very essential, and is exactly what is happening in the contacts app now. We cannot go straight from design to toolkit, having a prototype and using it in a number of apps for a while is important for weeding out the good ideas from the bad. (Designers are only humans too, after all, and come up with plenty of ideas that don't work out, just like the rest of us). Going from design/mockup straight into the toolkit is a recipe for the kind of issues we've had with e.g. the switch. And I don't think GTK+ developers implement the idea is scalable at all. If creating new widgets is too hard for average application developers, we need to make it easier. Of course, there is a big difference between a prototype that matches the mockup and a widget that meets the quality standards of GTK+, and this is where I see GTK+ developers come in: reviewing the prototype, making sure it matches the API conventions of GTK+ and is properly bindable, flippable, accessible, themable, etc... One thing that seems clear is that we can't have the toolkit become just a collection of UI paradigms of the past. It needs to keep evolving. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I have a problem
On Sun, May 29, 2011 at 1:06 AM, Paul Davis p...@linuxaudiosystems.com wrote: On Sat, May 28, 2011 at 5:01 PM, Benjamin Otte o...@gnome.org wrote: this is a cart vs. horse problem. i think you're absolutely correct that functionally, this is identical to a notebook. but there's function, and there's design. this design calls for an alignment of UI elements that isn't possible to accomplish with the current widget set (how would you get that More combo/menubar/button into the tab list?). is the design wrong to attempt that? if its wrong, why? if its right, how to accomodate the design if the current widgets don't. Just as a FYI: In this particular case, GtkNotebook supports action widgets, which would solve this particular problem. See http://blogs.gnome.org/johannes/2009/11/09/gtknotebook-action-widgets/ for an intro from when they were added. in most of what you've written here, you seem to put the widget set first, and you seem to be suggesting that UI design should work with the constraints that flow from the widget set, because that will result in good UIs. the other position is that good UI design should come first, and then the widget set and specific widgets need to be modified to accomodate the design(s). First of all, I would expect that I am biased towards the widget set, that comes from being one of the developers. ;) That said, let me get into how I think this whole interaction between designers and developers should work inside GTK. I envision the design process for new widgets or interactions to go something like this: 1) GNOME designers come up with an idea 2) GTK developers implement the idea 3) application developers and designers (both inside GNOME and ISVs) use it in their applications There's maybe a 1.5) GNOME ships a prototype application to test things in between. (Of course, this is not a top-down approach. Ideally the application developers provide feedback about how they think GTK should work to the GTK developers and the GTK developers When doing this thing though, we have to keep in mind the target audience for GTK. And we have to keep in mind UI design principles. Because the API of GTK is a user interface. And just like end users for GNOME, the end users of GTK - the developers writing applications - will look at what we give them and think about how to best use it to achieve their goals. Of course, they will not read the documentation, but infer something and then do what works. An example for this is the notification area. It was introduced in 2002/2003[1][2] and led a happy life until in 2005, when GTK introduced GtkStatusIcon. Suddenly, popping up an icon in the notification area became a trivial thing to do. Everybody saw it and thought Hey, my application could make use of that, too. and off they went. And now notification areas look like system trays on windows and are definitely not the thing we envisioned them to be. In fact, it goes so far that doing notifications in the shell is basically impossible. And I think a large part of the reason for the misuse is that we made it too freaking easy to use. Had it been a separate library, people would have used it a lot less. Just imagine if notification bubbles were as easy as a simple call to gtk_notification_show()... And of course, every time we support a new way to do things, there's a nontrivial cost involved in it. Apart from having to support it for at least this stable series, people will make use of it, find issues with it and demand new features.That means someone needs to take care of bugfixing, enhancements and so on. And when one day we decide to get rid of it, people will complain that their application is designed around this UI element we provided to them and expect us to have an easy upgrade path for them. Another thing that is quite important for me is to get people to do the right thing by default[4]. So when some non-GNOME developer decides to write an application with GTK, I want him to accidentally do the right thing. For example, if we decide applications should use Chrome-like overlays for status information it's probably a bad idea that we have a GtkStatusBar[5] aptly named for it, but doing the wrong thing. Same thing for toggles: Can we make it possible that developers decide between switch, checkboxes, radio buttons and toggle buttons correctly? Without reading any docs? Fwiw, getting this right not only helps make developers happy, it also helps designers - both because the apps are beautiful by default and because you have to file less UI bugs. ;) Benjamin 1: http://library.gnome.org/misc/release-notes/2.2/index.html 2: http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.1.html 3: http://developer.gnome.org/gtk/stable/GtkStatusIcon.html 4: http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html 5: http://developer.gnome.org/gtk/stable/GtkStatusbar.html ___ gtk-devel-list mailing list
Re: I have a problem
On Sat, 2011-05-28 at 23:01 +0200, Benjamin Otte wrote: And I'm somewhat lost what to do then. Should I say yes because it's a good widget to use in general? Should I say no, because it shouldn't be used? What are the features and behaviors I have to look out for in those widgets so they end up in a consistent toolkit? We sadly have not formalized this. This is definitely one of the things that we should try to do in the new HIG. Emmanuele mentioned the visual grammar, and I think this is the key here. There is already an architectural term for this; what Emmanuele thinks of as a visual grammar is the form language of an architecture. I'm going to mix architectural terms and computer science terms, so bear with me. Think of building materials as an alphabet, and their possible interactions as the grammar in your language. The possible constructions, or the strings in the language, are those that can be built with those materials by following their particular rules. Different architectures across the world have different form languages because they use different materials in different conditions. Brick and mortar buildings, with clay roof tiles on timber frames (Italy?) have a different look, and different shapes, than Japanese houses built of timber and movable paper walls. Each of those architectures has its own form language - and yet both let you build habitable buildings. In a similar fashion, GUIs have different form languages depending mostly on the toolkit. Qt apps look different than GTK+ apps even if you change the theme, because the forms and their interactions are different (and both let you build perfectly usable and attractive interfaces). The problem you are attacking is about trying to expand the form language we have. Maybe one question we need to ask is, does this look like it could come out naturally from GTK+, or are you cutting and pasting from an iPhone screenshot? (Would you put a brick arch to frame a door in your Japanese wood-and-paper house? No, you wouldn't; it would look terribly out of place.) I usually try to understand why the current widgets don't achieve the goal the design is trying to achieve and if we should modify the widgets to include the needed features. Or do the existing widgets not work for what we want to achieve and we should deprecate them? It depends. When we added icons and placeholder texts to GtkEntry, it was because those were useful forms that were very hard to build with what we had. Sometimes we need completely new stuff, like the button-that-when-clicked-brings-up-a-menu thing that everyone tries to implement in various ways, and with various degrees of success. * The text says Highlight and symbolic icon on hover indicates that the item is actionable So far we've not had icons anywhere in GTK that only show up on hover. Is displaying symbolic icons on hover a new UI paradigm that we want to promote? Should space for those icons generally be reserved in advance or should we reflow when they become visible? Or should they be drawn on top of existing content? Do we expect to use this paradigm in other places (menuitems or buttons come to mind) or is this just for contacts? This came from highly interactive web pages, and it's a good form. It lets you present affordances for functionality without cluttering everything (as if you had the icons visible all the time). I don't think we need a special widget for this; maybe just a GtkImage that the app turns on and off by hand when another widget is hovered - that's easy enough to do. We could have a gtk_image_set_active_only_when_hovered(image, other_widget), perhaps, if the implementation turns out to have more tricks than obvious. Space for the icons should definitely be reserved in advance; otherwise you don't have a guarantee that they'll fit to be visible. * The text says only the content gets scrolled That's where the designer probably got lazy^H^H^H^Htired as he was finishing the mockup. The heading area for Angelinus Jolie could very well be slightly wider horizontally, and the scrollbar shorter, so that the scrollbar really only adjoins the scrollable area. Look at the second picture in the first column of the mockup, where it shows the contents slightly scrolled. This looks bad: the top of the scrollable area has no frame and so the widgets get clipped (the fade-to-white is a bad, cheap effect). It would look even worse in the bottom when the gray button for Add detail gets clipped in the bottom of the scrollable area. That scrollable area just needs a border around it. * There's button(s) that say ( Notes | Edit ) How are these buttons different from notebooks? Is it just visually different or is it a completely different interaction? Because from the interaction described it looks like a notebook to me, just with a different UI. But I can't really pinpoint what's missing from GtkNotebook for this. Also, should we try to get rid of
Re: I have a problem
On Mon, May 30, 2011 at 23:33, Federico Mena Quintero feder...@ximian.com wrote: On Sat, 2011-05-28 at 23:01 +0200, Benjamin Otte wrote: * The text says Highlight and symbolic icon on hover indicates that the item is actionable So far we've not had icons anywhere in GTK that only show up on hover. Is displaying symbolic icons on hover a new UI paradigm that we want to promote? Should space for those icons generally be reserved in advance or should we reflow when they become visible? Or should they be drawn on top of existing content? Do we expect to use this paradigm in other places (menuitems or buttons come to mind) or is this just for contacts? This came from highly interactive web pages, and it's a good form. It lets you present affordances for functionality without cluttering everything (as if you had the icons visible all the time). Please, please explain me two things: 1. how I can to hover using touch screen? 2. why I (now as desktop user) should to hover anything just in case? Either I'm completely don't understand proposed design and use cases, or design is completely broken, or my understanding of convenience too far diverged from understanding of these designers. -- Andrew W. Nosenko andrew.w.nose...@gmail.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I have a problem
On Tue, 2011-05-31 at 01:53 +0300, Andrew W. Nosenko wrote: 1. how I can to hover using touch screen? You may not be able to (I don't know if X on your touch screen would emit proximity events). In that case, those UIs that require hovering may indeed not be adequate for your touch screen. Touch screens and mice have very different feels; you can't just use any widget and expect that it will work correctly on both types. 2. why I (now as desktop user) should to hover anything just in case? You shouldn't have to. If you need to scrape all the widgets just to find functionality, the design is indeed broken. What the appear-on-hover icons do is to present casually useful actions, not vital ones which should be close at hand. They are intended to be, by the way, you can also do this here, not the primary way of doing things. Think of the + icons that appear on YouTube's thumbnails so that you can add videos to your playlist (and in a similar way, the X icons that appear in thumbnails already in the playlist so you can remove them). You wouldn't want those icons to show up all the time; showing them when you hover the thumbnail is much better. And the icons are not the only way of performing their actions; you can go to the pages for the videos and find a remove this or add to playlist command in there - it just takes longer. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I have a problem
hi Benjamin; On 28 May 2011 22:01, Benjamin Otte o...@gnome.org wrote: Hey, I have a problem. I've not talked about this a lot, but it has crept up in my work of trying to improve GTK. It's the problem with how I see developers in GNOME currently approach developing the user interfaces for their applications. I have a feeling it goes something like this: - Someone comes up with mockup imagery. - Someone tries to make an implementation matches these mockups as exactly as possible. What these mockups usually do is present a visual design that cannot be achieved with the current GTK widgets. So what happens is the developers do is start writing a lot of widgets and trying to get them included in GTK (examples for that are GEditOverlay[1] or GtkSwitch[2]). And I'm somewhat lost what to do then. Should I say yes because it's a good widget to use in general? Should I say no, because it shouldn't be used? What are the features and behaviors I have to look out for in those widgets so they end up in a consistent toolkit? ignoring those two cases (I'll go back to them in a jiffy) I think the rule of thumb has been to include a widget in the toolkit if the design team has been using a UI visual element in different mockups for different components - i.e. if a widget is part of the visual grammar used to create the user interface. for GtkSwitch, the switch widget satisfied that requirement: every single hardware-related control panel item was designed with that particular UI visual element, and the design team also wanted to have that element in other applications outside of the control center domain. it was a tad hurried along, and since the interface guidelines haven't been updated along for the 3.0 UI because of its work in progress/point-zero release status, people started abusing it a bit. the GeditOverlay is another instance: it's used in different applications (Gedit, Epiphany, Nautilus) to implement the overlay message box/status area; it is a common element of the visual grammar for 3.0 applications. Is there any advice on the wikis or mailing lists or elsewhere[2] about what the overarching design rules are for GNOME3 that I should look for? Because whenever someone comes with it looks like this on the mockups I ask why does it look like this and not like that? and the only answer I get is dunno. the designers hold the keys for the visual (and interaction) aspect. the wiki and the git repository is a place to hold the reference, but you'll have to talk to the designers if you want explanations. I usually try to understand why the current widgets don't achieve the goal the design is trying to achieve and if we should modify the widgets to include the needed features. Or do the existing widgets not work for what we want to achieve and we should deprecate them? I think the visual styling is still a work in progress, and we should look at potentially fixing existing widgets - but if the end result is either a frankenstein monster of widget that can do four different styles (and I'm looking at you, GtkComboBox) and makes maintainership a misery, then we should probably looking at deprecating old widgets and introducing new widgets for the new visual designs. [snip] these questions are important, and I think the design team should work alongside the toolkit team to provide an answer; sadly, it's not as easy as it would be in an office - just get up, cross the room, and ask one of the design authors to comment on the behaviour, in my case. I also don't know whether the design team is all subscribed to the usability@ list, as they don't use emails to discuss. the #gnome-design channel is probably a better option, since Google killed Wave. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I have a problem
On May 28, 2011, at 2:01 PM, Benjamin Otte wrote: * There's button(s) that say ( Notes | Edit ) How are these buttons different from notebooks? Is it just visually different or is it a completely different interaction? Because from the interaction described it looks like a notebook to me, just with a different UI. But I can't really pinpoint what's missing from GtkNotebook for this. Also, should we try to get rid of notebooks and replace it with buttons like these in other places? I don't have a lot to say here, so I'll try to keep it brief. I think we need to approach many of these problems on a case by case basis. For example, in the notebook case, I think we can extract what the real problem is. The designer wants a way to switch between content within a particular area of the design. The fact that we attach notebook tabs to a side of this is simply one design metaphor for the act of switching. Perhaps, in this _one_ particular case, we need to extract the navigation of a stack of widgets from the stack of widgets itself, to fulfill the needs of the designers. Because, certainly, tabs can't be the solution to everything. (Breadcrumbs, nautilus navigation buttons, etc, all seem to fit within this metaphor). I understand that you can just use a radio button group to switch the pages manually while not showing the notebook tabs. I've certainly done that before, and maybe that is enough. I don't know. Cheers, -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
I have a problem
Hey, I have a problem. I've not talked about this a lot, but it has crept up in my work of trying to improve GTK. It's the problem with how I see developers in GNOME currently approach developing the user interfaces for their applications. I have a feeling it goes something like this: - Someone comes up with mockup imagery. - Someone tries to make an implementation matches these mockups as exactly as possible. What these mockups usually do is present a visual design that cannot be achieved with the current GTK widgets. So what happens is the developers do is start writing a lot of widgets and trying to get them included in GTK (examples for that are GEditOverlay[1] or GtkSwitch[2]). And I'm somewhat lost what to do then. Should I say yes because it's a good widget to use in general? Should I say no, because it shouldn't be used? What are the features and behaviors I have to look out for in those widgets so they end up in a consistent toolkit? Is there any advice on the wikis or mailing lists or elsewhere[2] about what the overarching design rules are for GNOME3 that I should look for? Because whenever someone comes with it looks like this on the mockups I ask why does it look like this and not like that? and the only answer I get is dunno. I usually try to understand why the current widgets don't achieve the goal the design is trying to achieve and if we should modify the widgets to include the needed features. Or do the existing widgets not work for what we want to achieve and we should deprecate them? I'll now going to use a GNOME Contacts mockup[4] to list a few examples for cases where I'm struggling with what to say. They are by no means meant personal, neither towards the developer implementing them, nor towards the designer who did the mockups. It is just the last example of where I found this problem, so it's freshest in my mind. So let's go from top left to bottom right: * The text says Highlight and symbolic icon on hover indicates that the item is actionable So far we've not had icons anywhere in GTK that only show up on hover. Is displaying symbolic icons on hover a new UI paradigm that we want to promote? Should space for those icons generally be reserved in advance or should we reflow when they become visible? Or should they be drawn on top of existing content? Do we expect to use this paradigm in other places (menuitems or buttons come to mind) or is this just for contacts? * The text says only the content gets scrolled This looks to me like there's this new idea of putting more static content into scrollable areas to allow the scrollbars to be wider. Now we obviously do not have a scrollable widget to embed static content, the only widgets that do that have special code for it (treeview headers for example). Do we expect this to happen more often and should we have a widget? Do we expect this to transition to other scrolling interfaces like panning on touchscreens or Ubuntu's new scrollbars? How should this static content interact with vertical scrollbars? Was the designer doing this aware of the fact that we cannot currently do fade-in/out of adjacent widgets, so the nice fade effect in the mockup is almost impossible to write in a generic way? Even if this was possible, how would this interact with the scrolling content? Should the content be scrollable until it's no longer below the fade effect or should it not be possible to make the topmost N pixels of the scrolling content come out from under the fade? And how should this interface interact with widgets with non-scrollable content like treeview headers? * There's button(s) that say ( Notes | Edit ) How are these buttons different from notebooks? Is it just visually different or is it a completely different interaction? Because from the interaction described it looks like a notebook to me, just with a different UI. But I can't really pinpoint what's missing from GtkNotebook for this. Also, should we try to get rid of notebooks and replace it with buttons like these in other places? * The [ More v ] button So there's this button that pops up a menu, so it's somewhere between a menubar, a combobox and a button. Now, how should this behave? How should it look? Wow, that's already long. I'll leave it at that. I think it gives examples for everything I want to say already. Just one more example because I've been encountering it in a lot of places: * Overlays/Popups It seems a lot of designs overlay things on top of existing widgets. It seems a bit like the modern version of dialogs. GEditOverlay is an example for this, the contacts example[4] has it for its [ More v ] menu and when showing the Embedded image. The menus design page[5] is an obvious example. What is the interaction for those overlays and popups? Is it ok if there are multiple of those? Are they modal? Should a user be able to get rid of them to get access to the content they overlap? How? What's the intended interaction with them? Are they focusable? Clickable
Re: I have a problem
On Sat, May 28, 2011 at 5:01 PM, Benjamin Otte o...@gnome.org wrote: so lets take this particular point as an example of what i think the basic problem is here: * There's button(s) that say ( Notes | Edit ) How are these buttons different from notebooks? Is it just visually different or is it a completely different interaction? Because from the interaction described it looks like a notebook to me, just with a different UI. But I can't really pinpoint what's missing from GtkNotebook for this. Also, should we try to get rid of notebooks and replace it with buttons like these in other places? this is a cart vs. horse problem. i think you're absolutely correct that functionally, this is identical to a notebook. but there's function, and there's design. this design calls for an alignment of UI elements that isn't possible to accomplish with the current widget set (how would you get that More combo/menubar/button into the tab list?). is the design wrong to attempt that? if its wrong, why? if its right, how to accomodate the design if the current widgets don't. in most of what you've written here, you seem to put the widget set first, and you seem to be suggesting that UI design should work with the constraints that flow from the widget set, because that will result in good UIs. the other position is that good UI design should come first, and then the widget set and specific widgets need to be modified to accomodate the design(s). in this case, that would imply a rather complicated change (or maybe its simple) to the notebook widget. so there are 4 choices: * possibly complex and far-reaching changes to existing widgets - no new widgets, but the design can be supported * new widgets - creates ambiguity in the widget set, but the design can be supported * modify the design so that it can implemented with existing widgets * reject design because the widget set can't support it my feeling on this is that it depends a lot on the quality of the design and the resistance on the part of the designer to modifying it so that the design can be implemented using the existing widget set. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I have a problem
Le 29/05/2011 01:06, Paul Davis a écrit : On Sat, May 28, 2011 at 5:01 PM, Benjamin Otte o...@gnome.org wrote: so lets take this particular point as an example of what i think the basic problem is here: * There's button(s) that say ( Notes | Edit ) How are these buttons different from notebooks? Is it just visually different or is it a completely different interaction? Because from the interaction described it looks like a notebook to me, just with a different UI. But I can't really pinpoint what's missing from GtkNotebook for this. Also, should we try to get rid of notebooks and replace it with buttons like these in other places? this is a cart vs. horse problem. i think you're absolutely correct that functionally, this is identical to a notebook. but there's function, and there's design. this design calls for an alignment of UI elements that isn't possible to accomplish with the current widget set (how would you get that More combo/menubar/button into the tab list?). What about gtk_notebook_set_action_widget()[1]? OK it doesn't look exactly the same as the tabs, but it's positioned at the very suggested place. A few ¢ Colomban [1] http://developer.gnome.org/gtk/stable/GtkNotebook.html#gtk-notebook-set-action-widget ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I have a problem
On Sat, May 28, 2011 at 9:31 PM, Colomban Wendling lists@herbesfolles.org wrote: Le 29/05/2011 01:06, Paul Davis a écrit : this design calls for an alignment of UI elements that isn't possible to accomplish with the current widget set (how would you get that More combo/menubar/button into the tab list?). What about gtk_notebook_set_action_widget()[1]? OK it doesn't look exactly the same as the tabs, but it's positioned at the very suggested place. i had a nasty feeling when i typed that line that there actually was a method to do this, but forgot to check :) thanks for correcting me. i'm not sure it makes the rest of what i wrote wrong, but its a good counterpoint in this particular example. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Howto make GtkRadiobutton text flicker (was: Re: I have a problem with GtkRadioButton)
yeajchao wrote: However, the need for some applications to use fixed colours like green, yellow and red to indicate things like error-free results, warnings, error messages or critical choices / operations is recognized. That's why you can rather easily change colours and appearances of texts on screen. See the following URL for an overview of how to change text appearances of markup-enabled widgets even easier than tweaking themes: First,thank you very much for your advice As you say, I want to use the radio button as a alarm, Usually,alarm's color is red My application controls some peripheral instrument, when my application detected some one broken down the alarm will be flicker with red color I am a beginer of gtk, also beginer of program,so I have no other idea toresolve the problem Will you be so kind as to give some advice ? First: you really should forget about manually recolouring the knobs of radiobuttons, checkboxes and other controls. Recolouring just texts is sufficient for this purpose and can be accomplished almost easily. To make text(s) in dialogs flicker there are about four steps to be taken. I assume you have your standard GtkRadiobutton* (the one to be recoloured) within reach. In this example I will call it rb_flicker: 1. learn about Pango's simple markup to apply custom colours (and other styles) to labels. See: http://developer.gnome.org/doc/API/2.0/pango/PangoMarkupFormat.html 2. obtain the GtkLabel that is (usually) associated with a GtkRadiobutton. The simpliest way to get it is about this: label_flicker = gtk_bin_get_child (GTK_BIN (rb_flicker)); See: http://developer.gnome.org/doc/API/2.0/gtk/GtkBin.html#gtk-bin-get-child 3. use gtk_label_set_markup() to change the appearance of the label once, something like this: gtk_label_set_markup (label_flicker, span foreground=\red\This is critical/span); See: http://developer.gnome.org/doc/API/2.0/gtk/GtkLabel.html#gtk-label-set-markup 4. to actually achieve a flicker effect (periodically changing appearance) you manually have to change the markup text of the label periodically. There are no automatic means to achieve any sort of animation in GTK+. Use one of gtk_timeout_add() or g_timeout_add() to register a simple function which periodically switches between two (or more) states of the label, like 1. span foreground=\red\This is critical/span and 2. This is critical. This switches between red and default colour of the text. Upon registration, this simple markup changer function should receive the GtkLabel of the GtkRadiobutton as its data, like this: gtk_timeout_add (500, func_flicker, label_flicker); See: http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html#gtk-timeout-add http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-timeout-add Notes: Step 2, as described here, assumes you are using a simple radiobutton, that is, a GtkRadiobutton with exactly one GtkLabel attached to it. GTK+ also supports more complex radiobuttons which have containers and multiple children, i.e. images, attached to them, instead of just a simple GtkLabel. In that case locating the GtkLabel would require some more efforts. Step 4: it is up to you to take care to stop the periodically called timeout function. For instance, when the dialog that contains the flickering radiobutton gets destroyed, the flicker function MUST NOT continue to try changing the appearance of the radiobutton's label any more. Removal of your timeout fucntion does not happen automatically! After all I'd like to repeat: you shouldn't play with the appearance of GTK+ widgets in a custom, non-themable way unless absolutely required! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
I have a problem with GtkRadioButton
Hello all First of all, I apologize for my terrible english! I have a problem with GtkRadioButton. You know,when you select a GtkRadioButton,there will be a big point placed in the circle of the radio button .It maybe called indicator. My problem is that: I want to change the indicator's color to red or some other color,but I don't know how to do that. Is there anybody want to help me? Any help would be much appreciated! I tried to edit my gtkrc file but this seems just change the text's color of the ___ 雅虎1G免费邮箱百分百防垃圾信 http://cn.mail.yahoo.com/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
