Bug 3818 - (int-153819) Missing Icon Naming Specification compliance makes porting apps unneededly complicated
: Missing Icon Naming Specification compliance makes porting apps unneededly co...
Product: Desktop platform
: 5.0/(2.2009.51-1)
: All Linux
: Low enhancement (vote)
: ---
Assigned To: unassigned
: icons-bugs
  Show dependency tree
Reported: 2008-10-24 10:08 UTC by Thomas Perl
Modified: 2011-01-17 21:42 UTC (History)
3 users (show)

See Also:



You need to log in before you can comment on or make changes to this bug.

Description Thomas Perl (reporter) 2008-10-24 10:08:44 UTC
Port an application that makes use of the default gnome-icon-theme.

All icons are available.

Many icons are missing, and the relevant hildon icons have different names! I
need to introduce special-cases for my app's maemo port, opening different
icons instead of standard ones.



If you provide gnome-icon-theme, or at least a hildon theme that has the same
icon names as the gnome-icon-theme, this makes porting of Desktop Linux
applications easier. Currently, this is an additional step in porting apps
(correcting the icon names from "normal" Desktops to hildon-specific ones).
Comment 1 Ryan Abel maemo.org 2008-10-24 10:47:52 UTC
Related to bug #223, perhaps?
Comment 2 Thomas Perl (reporter) 2008-10-24 21:02:50 UTC
To elaborate a bit more, in gPodder, I have the following ugly "if"s for the
Maemo-specific icons. What I would like is either a complete, supported
gnome-icon-theme (which would just need packaging, or simply taking it from
Debian) or make your icon names compatible with the gnome-icon-theme / icon
naming specification.

Ideally, I won't need these "if"s in my code, but simply have a working and
complete icon theme on Maemo, too. Other projects would surely also benefit
from this - either because they are porting projects, or because developers
familiar with GTK+ on Desktop Linux can use their knowledge of the icon naming
specification to use the icons instead of hunting for the icons in the SDK and
picking some obscure names (...qgn_indi_KeypadLk_lock...).

if gpodder.interface == gpodder.GUI:
    WEB_BROWSER_ICON = 'web-browser'
elif gpodder.interface == gpodder.MAEMO:
    WEB_BROWSER_ICON = 'qgn_toolb_browser_web'

if gpodder.interface == gpodder.GUI:
    ICON_LOCKED = 'emblem-nowrite'
elif gpodder.interface == gpodder.MAEMO:
    ICON_UNPLAYED = 'qgn_list_gene_favor'
    ICON_LOCKED = 'qgn_indi_KeypadLk_lock'

if gpodder.interface == gpodder.MAEMO:
    ICON_AUDIO_FILE = 'gnome-mime-audio-mp3'
    ICON_VIDEO_FILE = 'gnome-mime-video-mp4'
    ICON_BITTORRENT = 'qgn_toolb_browser_web'
    ICON_DOWNLOADING = 'qgn_toolb_messagin_moveto'
    ICON_DELETED = 'qgn_toolb_gene_deletebutton'
    ICON_NEW = 'qgn_list_gene_favor'
    ICON_AUDIO_FILE = 'audio-x-generic'
    ICON_VIDEO_FILE = 'video-x-generic'
    ICON_BITTORRENT = 'applications-internet'
Comment 3 Thomas Perl (reporter) 2008-10-24 21:08:47 UTC
Alternatively, just comply with the Icon Naming Specification and don't provide

Comment 4 Quim Gil nokia 2008-10-27 09:45:19 UTC
Point taken. Having Icon Naming Specification compliance sounds like a
preferrable way to solve this issue since this should make just as happy the
Qt/KDE folks and etc. Subject changed and also listed at
Comment 5 Andre Klapper maemo.org 2009-12-30 15:53:33 UTC
Thomas, is this still valid for Maemo5? If so, can you please update the
Version field?
Comment 6 Thomas Perl (reporter) 2009-12-30 16:23:37 UTC
Still an issue in 2.2009.51-1:

/usr/share/icons/hicolor/ contains all the icons (which is okay), but
most of them are in the "hildon" context (see the spec for the list of
contexts), and the icon names could be renamed to be more compliant
to the naming spec, e.g.:

 * Spec says "user-available", Maemo has "general_presence_online"
 * Spec says "user-away", Maemo has "general_presence_away"
 * Spec says "media-playlist-shuffle", Maemo has "mediaplayer_default_shuffle"
 * Spec says "audio-volume-muted", Maemo has "statusarea_volume_mute"
 * Spec says "battery-low", Maemo has "statusarea_battery_low"
 * Spec says "audio-x-generic", Maemo has "general_audio_file"
 * (there are several more, these are just examples)

In addition, the MIME type icons (specified in "Standard MIME
Type Icons" in the spec) are wrongly named (they still have
the [legacy?] gnome-mime- naming):

(see all with "find /usr/share/icons/hicolor | grep gnome-mime")

In general (sic), most icons have "general_" in front of them
and are in the "hildon" context, when they could be placed
somewhere else:

 * general_map -> apps/map
 * general_skype -> apps/skype
 * general_ovi_store -> apps/ovi_store
 * general_web -> apps/web-browser
 * general_add -> actions/add

I also suggest that the Maemo team works together with the
people from the icon spec to add any "mobile phone-specific"
icon names that are not yet defined in the spec, but are
important and useful in the context of a mobile phone to
the spec, so that other implementations use the same name.

This should also make it easier to make Maemo more themeable
by simply being able to install a "generic" icon theme and
have most icons (with fallbacks to Maemo's default icons) be

If you need any more information, I'd be happy to help, as
this is one of the annoyances when trying to maintain apps
for both "mainstream" Desktop Linux and Maemo. As the spec
is relevant for both Gnome and KDE, I'd say that this is also
very important for future Qt-based products, as porting KDE
applications will then be easier, too.
Comment 7 Andre Klapper maemo.org 2011-01-17 21:42:47 UTC
Internal comment:
"We are not going to change the names of the icons at this point for Maemo5."
Closed as WONTFIX for Maemo5 - reflecting state here.

MeeGo Handset is where the unstable development is taking place. If you are a
developer (not a "normal" user) feedback about / retesting on MeeGo Handset
issues is specially welcome, e.g. via the MeeGo bugtracker at
Please note that MeeGo for the Nokia N900 is unstable and by no means ready for
end-users. See http://wiki.meego.com/ARM/N900 for more information and be aware
of the risks of trying unstable software.