maemo.org Bugzilla – Full Text Bug Listing
|Summary:||GtkRadioButton should look like a Maemo 5 radio button|
|Product:||[Maemo Official Platform] Desktop platform||Reporter:||Murray Cumming <murrayc>|
|Status:||RESOLVED WONTFIX||QA Contact:||gtk-bugs|
|Priority:||Low||CC:||agarcia, andre_klapper, ext-mox.soini, quim.gil|
Apparently Maemo 5 radio buttons should look like toggle buttons. See https://bugs.maemo.org/show_bug.cgi?id=4577 I personally think that's unwise, but that's how it is. Maemo 5's GTK+ should achieve this cosmetic effect via the theme. Currently, the coder must use gtk_toggle_button_set_mode() on each GtkRadioButton to achieve this. http://library.gnome.org/devel/gtk/stable/GtkToggleButton.html#gtk-toggle-button-set-mode Or, presumably the same thing can be achieved by using hildon_gtk_radio_button_new() instead of gtk_radio_button_new(). Either way, it is a change to the API, and all such API changes require an ifdef for ported code, and make general GTK+ documentation invalid for Maemo.
We've been discussing this in the maemo-developers mailing list. As Murray says, "classic" radio buttons are not recommended in Maemo 5. If an application really wants to use radio buttons, they should be grouped together visually and look like toggle buttons. I don't think it's possible to change that using the theme alone. Also, as there's standard (and simple) GTK API for that (gtk_toggle_button_set_mode()), I think that it's fine as it is now and that Maemo-GTK doesn't need to be changed. And anyway I don't think it's a good idea to change the style of all radio buttons unconditionally. User interfaces written specifically for Maemo 5 should be designed with that in mind and use that API. In legacy (i.e, non-Fremantle) applications, making all radio buttons look like toggle buttons by default could do more harm than good, even if radio buttons are not recommended.
While any app written for Maemo 5 really _should_ use Hildon 2.2 UI Style, there are still applications which use Maemo 4 style (at least for the time it takes for developers of the existing Maemo 4 apps to port the UI, should they be willing to do so). We cannot just break all the Maemo 4 style apps by unconditionally forcing the Maemo 5 looks and sizes to Maemo 4 apps. And since even mixing Maemo 5 and Maemo 4 styles is possible within single application, there isn't a good way to get the Maemo 5 radiobuttons without using some extra commands/API (== gtk_toggle_button_set_mode() or hildon_gtk_radiobutton_new()). ... I'm sure if all the legacy compatibility would be thrown out, we'd have VERY different looking API in total. But then, nobody's seriously wanting to do that.
This is all a matter of opinion of course, but in my opinion all Maemo 4 apps are "broken" until they are ported. The non-deprecated part of the API is just too different. If Maemo 4 API is allowed for any reason in Maemo 5 then a) it should not be deprecated and b) the HIG should suggest where it might be allowed.
(In reply to comment #3) > This is all a matter of opinion of course, but in my opinion all Maemo 4 apps > are "broken" until they are ported. The non-deprecated part of the API is just > too different. Opinions indeed. While I think everyone indeed should use Maemo 5, I don't expect to see that fully happening within, let's say, a year. What do you then do to those maemo.org's Maemo 4 apps during that "transitional" period? They don't run on the new SDK at all? Or are so broken that they are not usable at all? I've heard that one of the motivations to port to Maemo is that you can run a desktop Gtk app on Maemo almost with no changes. That gives a sort of instant gratification. And then allowing to tweak the app towards Maemo UI piece by piece. ... Note, I'm NOT, suggesting anybody to use Maemo 4 style when developing for Maemo 5. I think that would be a very bad idea.
Mox / Quim: Realistically speaking (not putting too much efforts into gtk+ in Maemo5 as Qt will take its place in maemo6) I assume that this request is a WONTFIX, or is there a chance left to handle this?
I think it's quite obvious that this is not going to be changed