maemo.org Bugzilla – Bug 4578
GtkRadioButton should look like a Maemo 5 radio button
Last modified: 2010-07-14 13:35:19 UTC
You need to
before you can comment on or make changes to this bug.
Apparently Maemo 5 radio buttons should look like toggle buttons. See
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
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
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
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
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
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
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