Please improve/clarify the Icon Theme Specification
waldo.bastian at intel.com
Thu Jun 8 02:25:57 EEST 2006
Great feedback, thanks. Regardless of which proposed changes will get
adopted I would like to express a strong desire for the directory
structure to remain unchanged.
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/go/linux
OSDL DTL Tech Board Chairman
>From: xdg-bounces at lists.freedesktop.org [mailto:xdg-
>bounces at lists.freedesktop.org] On Behalf Of Pascal De Vuyst
>Sent: Wednesday, June 07, 2006 2:58 PM
>To: xdg at lists.freedesktop.org
>Subject: Please improve/clarify the Icon Theme Specification
>Please clarify the Icon Theme Specification for the points mentioned
>Please mention that "Directories" are searched from left to right for
>first match. The same applies for Inherits. This is not clear now.
>Clarify what Type=Threshold means.
>If I understand correctly this is used to match icon sizes that differ
>plus or minus the Threshold value from the requested size.
>This is best illustrated with the KDE versus GNOME menu icons.
>GNOME uses 24x24 pixel menu icons and KDE 22x22 pixel menu icons.
>Let's say we have a KDE icon theme with 22x22/apps icons that would be
>used in GNOME. For the 22x22/apps directory Type=Treshold is set with
>the default Treshold value of 2 pixels. This icon directory would match
>the requested size of 24 pixels for the GNOME menu. It is not clear in
>the current specification how the implementation would handle the 22x22
>to 24x24 pixel transformation. The best way would be to add a 1px
>transparant padding border around the 22x22 icon creating a 24x24 icon
>(this is also suggested by tango project). The current implementation
>for GNOME seems to upscale the 22x22 icon to 24x24, this makes the icon
>look very blurry. I think the padding is a better solution and this
>should be suggested in the specification.
>Now look at the other side and say we have a GNOME icon theme with
>24x24/apps icons that would be used in KDE. For the 24x24/apps
>Type=Treshold is set with the default Treshold value of 2 pixels. This
>icon directory would match the requested size of 22 pixels for KDE
>It is not clear in the current specification how the implementation
>would handle the 24x24 to 22x22 pixel transformation. Most icons have
>some free space around the icon, the best way would be to remove a 1px
>border from the 24x24 icon creating a 22x22 icon (clipping). If the
>icons don't have enough free space for clipping it, it should be
>downscaled to 22x22 pixels. This should be suggested in the
>Please mention that the Threshold value is in pixel size, in the
>explanation you could think it is some kind of scaling factor.
>Context=Applications is listed under section Example but not described
>under section Context. It would be better to refer to the Contexts and
>directory names described in the Icon Naming Specification or include
>this also in the Theme Specification. The directory structure should be
>part of the Icon Theme Specification.
>The current specification suggests that 3rd party application icons
>should be in the hicolor fallback theme.
>I have the following issue related to this:
>Currently I have gnome installed with some extra KDE apps. By
>the KDE apps the default KDE icon theme (crystalsvg) is also installed.
>The standard theme inherit order used by GNOME seems to be:
>Inherits=default.gnome,default.kde,hicolor. Use of default.kde makes
>sense since we want to see the KDE icons for the installed KDE apps.
>Now the problem is default.kde contains icons for third party
>applications, e.g. gaim. This means that when I select for instance the
>Tango icon theme that doesn't have an gaim icon, it falls back to the
>default.kde icon for gaim. This is unexpected, I would expect to see
>gaim icon from hicolor fallback theme in my GNOME installation.
>Changing the standard theme inherit order for GNOME to:
>Inherits=default.gnome,hicolor,default.kde,default.xfce would solve
>problem. According to the icon theme specification hicolor should
>be the last fallback theme, these multi desktop environment issues
>should be adressed in the icon theme specification.
>Some remarks about hicolor icon theme.
>The specification doesn't say anything about the use of Type=Scalable
>for bitmap icons it only suggests at least a 48x48 png icon. A 48x48
>icon could be provided for an application and Type=Scalable in
>combination with MinSize and MaxSize would allow this icon to be scaled
>down. For the hicolor fallback theme this would be enough.
>Therefore /usr/share/icons/hicolor/index.theme should be changed to
>contain the following:
>This will make 48x48 png application icons downscalable to 16x16 pixels
>for window list icons, to 24x24 for GNOME menus and panel icons and to
>22x22 for KDE.
>There is no need to provide 16x16, 22x22 or 24x24 versions in the theme
>when they are just downscales of the 48x48 icon, the downscaling could
>be done by the implementation and gives the same result.
>Currently if I look in hicolor icon theme scalable/apps directory in my
>GNOME distribution I see some 3rd party applications provide svg with
>48x48 nominal size and other svg with 128x128 nominal size.
>The problem with this is that 48x48 icons appear to small on the
>because of the wrong Size=128 indication.
>To address this I think the (sub)directory structure should be changed
><icon type>/<nominal size>/<category>/<subcategory>
><icon type> = "bitmap" for png/xpm or "scalable" for svg/svgz.
><nominal size> = nominal size of png/pxm or svg in format width x
>without spaces, e.g. 48x48.
><category> = apps, filesystems, ...
>The <nominal size> indication will make it easier for people to respect
>the nominal size for icons in the directory and therefore will avoid
>wrong scaling on the desktop.
>The (sub)directory structure would make the Size key optional since the
>size can be found in the <nominal size> subdirectory name.
>As example, this should be included in hicolor icon theme:
>Thanks in advance,
>Pascal De Vuyst
>xdg mailing list
>xdg at lists.freedesktop.org
More information about the xdg