This will explain app icons and how to create them for Linux apps.
It is mostly about the icons used in the desktop metaphor, to represent apps and the documents that apps create/understand.
This blog is a log of many websites I visited, tilting at windmills, trying to make sense of ever changing chaos.
App icons defined
App icons are a set of icons (AppIconSet) that represents an app and its documents to a user of an OS that uses the desktop metaphor.
An AppIconSet can be an improper set: having only one image. The same image CAN be used for AppIcons and MimeTypeIcons. A user can usually distinguish the two uses: in one use the icon has the app name beneath it, and in the other use, the icon has a document name beneath it. This gets into politics, when an app and the mimetypes it creates are proprietary, the same icon could be used, but once the mimetype becomes a standard, one app should not put its icon on documents.
One definition of the word icon is: an image that represents.
In this context, an icon as a displayed image means a bitmap image, and a smallish one, a few centimeters, and a few tens of pixels in resolution. Icons as displayed may be generated from vector graphic images. It is important to distinguish icon as a source file of displayed images. This post itself does not always keep the distinction clear.
A quick summary is: modern OS’s and their desktops need a scaleable image as a source file of displayed image icons. That is, SVG is built into the OS and desktop. ‘Modern’ means in the last few years. SVG in KDE describes KDE’s new support for scaling icons.
User Interface Guidelines
These documents are mostly about graphic designing icon images, with some mentions of responsibilities for app installations.
- FreestandingIcons: higher resolution, more realistic
- ToolbarIcons: in toolbars, simplified (outline)
- SidebarIcons: in sidebars, simplified (outline), and invertible
- Button icons: in buttons, having images for states of the button
- AppIcons: applications
- MimeTypeIcons: documents, with badges
- PlaceIcons: disk, trash, Web, etc.
These are subclasses in the sense that the behaviour is different, at least to a user, if not to a programmer.
In this document, I use app icon to mean AppIcons and MimeTypeIcons: the installation of a document viewing or editing application is often responsible for both (when an app establishes its own mimetype.) But I am excluding WidgetIcons, the icons that an app uses internally, that is, the icons that an app provides as resources for its own toolbars, sidebars, and other widgets.
AppIcon and MimeTypeIcon images can share drawing elements or motifs:
- for branding purposes, in the case of proprietary apps
- as a user interface strategy to show relations between an app and the documents it creates or understands
For example, the same motif of a music note can appear in related AppIcon and MimeTypeIcon.
App icons and GUI Frameworks e.g. Qt
It is NOT the responsibility of the framework to provide FreestandingIcons; that is the responsibility of the packaging.
In Qt, QWindow.setWindowIcon() puts a ToolbarIcon in the window’s title bar. This is for main (top) windows only, so that in an application that has many top windows, a user can know which app the window belongs to? This is the responsibility of the app. This is optional, since the text of the titlebar may serve the same purpose?
Qt has other functions for getting WidgetIcons, including ‘standard’, cross-platform icons, and themed icons. (Beyond the scope.)
App icons as sets
OS’s usually require OR allow (of a program to be installed) a set of icon images, at different resolutions (and corresponding use in different displayed real sizes.)
It would be nice if an OS required only one icon image and generated displayed icon instances of different resolutions. To some extent, this is possible.
However, to algorithmically generate low resolution images, i.e. icons or thumbnails, from high resolution bitmaps, is a hard problem in computer graphics algorithms. (Search under “summarizing visual data”.) Also, much has been written (enough to clog the search for the topic of this post) about how to manually create an icon set of bitmaps, tweaking pixels of each icon.
It is NOT so a hard problem to generate low resolution bitmap images from scalable images, and this is what modern OS and desktops do.
OSX accepts icons in PDF and generates icons of higher resolution from them.
The Freedesktop org spec for icon themes also specifies (vaguely) how to use scalable graphics for icons.
The requirement for a set (of displayed bitmaps) is a user interface design issue:
- freedom for users to choose a size
- comfort for users, when higher resolution and larger size lets them recognize an icon (it fails as an icon if the user doesn’t recognize it.)
The requirement for a set is also a business and software system issue:
- provided as a service at installation time by a software package to a package manager client
- provided as a service by a package management system to desktop browser clients
Who is responsible for creating the set, especially from a single scalable image? Recently, the answer has become: the OS and desktop are responsible for generating the set from a scalable image that you provide in the install package.
Vector graphics and icons
Scaleable vector graphics (SVG and PDF formats are both scalable) scale without loss of resolution. However, an SVG and PDF file may contain (embed) a bitmap image that won’t scale without loss of resolution. When a spec for icons says scalable graphic image, do they mean one with embedded bitmap? I don’t think so.
When a spec for icons says a scalable graphic image of a certain size (say 64×64) , why the size requirement? I think that is overspecifying. After all, scalable means it can be rendered in any size.
What size icons does each Linux platform require in an icon set? Icon Themes
Debian is not concerned with AppIcons. They are only a concern of desktops.
The Freedesktop organization document entitled “Icon Theme Specification” defines the minimum requirements. It is a ‘pseudo’ standard, a convention.
A user thinks of a theme like a graphic designer, and that document is largely about that kind of ‘theme’. But the document describes a ‘default theme’ (name ‘hicolor’.) An IconSet is a component of a theme, so this document describes the minimum requirement for app icons:
So, you’re an application author, and want to install application icons so that they work in the KDE and Gnome menus. Minimally you should install a 48×48 icon in the hicolor theme. This means installing a PNG file in $prefix/share/icons/hicolor/48×48/apps.
But it also vaguely talks about SVG files in this and other directories.
But the two competing desktops: Gnome and KDE, and value-adding distributors such as Ubuntu, may have further requirements.
The different sizes are used by different utility apps of the desktop (Launcher, Dash, Ubuntu Software Center, Nautilus). But this doesn’t mean you as a packager must provide the icon set.
(I don’t know where a requirement is strictly specified.)
A brute force strategy for creating an icon set
If your goal is: a crude AppIconSet that works on most Linux platforms, even older distributions, then you can adopt this strategy:
- create a scalable image that is is very simple, an outline and contours, black and white image
- generate the set of icon bitmaps in resolutions (sizes) that covers all the platforms: 16, 22, 32, 48, 64, 128
- put those icons in your package
You can use Inkscape for both creating the scalable and bitmap images.
You might use this strategy if you are very concerned about the quality of your displayed icons.
A simple, modern strategy
If your goal is: the minimum work on your part to get some icon representing your app on the desktop:
- create an SVG image (e.g. using Inkscape).
- put that image in the default icon theme at /usr/share/icons/hicolor/scalable
The units and value of the size of the SVG image doesn’t seem to matter, but at least in Inkscape, the size DOES matter in this way:
- your drawing should fill the size and be contained in the size
- the shape should be symmetrical (e.g. a square or a circle)
(I think this is a flaw of Inkscape or the OS that displays the SVG as an AppIcon: the size of the area that the drawing elements cover (the bounding rect) should be determined at rendering time, not specified in the SVG.)