Icons

This pages is a collection of information regarding the implementation of icons inside of Inkscape.

Overview

Inkscape's interface makes extensive use of custom icons, and now provides a few mechanisms and different code to handle them. Over the years this area has seen distinct approaches taken, and has needs to move completely away from legacy approaches.

Aside from the state of the code, this section also covers some of the details on themes and how to and and implement icons, along with some of the internal details and design issues related to the implementation.

History

Icon support in Inkscape has a long history and has accumulated a fair bit of cruft along the way. Originally the icons were custom widgets with all functionality shoved mainly into a single C source file. Standard GTK+ mechanisms had been originally avoided by a legacy design decree. However once the icon code was revisited that avoidance was dropped and work started (slightly sporadically) to move to standard GTK+ widgets and mechanisms. This includes the fact that the original SPIcon came from the GTK+ 1.x time frame, and predated GTK+ 2.x.

SPIcon

SPIcon was the original custom widget class used to represent icons, along with all the code needed to load the images to be used. A mix of pixmaps and then internally generated pixmaps from a common SVG was used.

So two main aspects exist here. First is the widget class itself that draws a visible image. Second is the code to load and cache the images used. Keep in mind that a single icon name might be used for several different sized display widgets.

Themeable Stock Icons

Themeable Stock Images were added to GTK+ with the major jump to GTK+ 2.0. Some nice features were that they allowed a program to as for logical size icons and get different physical size images depending on how the user's overall theme was configured, could manage those multiple sizes, could store extra info such as name, and could have extra varients including right-to-left vs. left-to-right versions.

Probably the #1 usability item here is the support for logical sizes. So a program author can code in "get the menu-sized icon image" and get back a 16x16 image on one system, and get a 24x24 on a system with a high resolution display. OR the theme could also be set to return a 24x24 image for the low-res monitor in the cases where a user had eyesight that required a larger size.

Some work was begun to migrate Inkscape to use Themeable Stock Images, but the APIs themselves did not take into account that a program might want to provide it's own scalable set if images... and thus much prerendering was needed.

One of the more recent bits of coding on Themeable Stock Images support was to change things to not take the internal icons.svg versions, and instead fall to system icons when present. Much of this was done in coordination with Andreas Nilsson, Rodney Dawes Jakub Steiner and others to try to better support Tango and also the Icon Naming Specification.

In order to maximize user benefit, applications should share common icons for common tasks. freedestop.org listed out names for core "office" functionality, but graphics and media programs were left out.

The intent was for authors of graphical and other artistic programs to list the common functionality needed and agree on names to use for the common concepts. This was the ArtLibreSet. Unfortunately developers of other graphics projects did not care to share common icons, and Inkscape was one of the only ones to make suggestions.

GtkIconTheme (named icons)

GtkIconTheme was added into GTK+ as of version 2.4. As to the difference from Themeable Stock Icons, the documentation mentions:

"A good rule of thumb is that if there is a stock image for what you want to use, use it, otherwise use a named icon."

Work was started in order to leverage GtkIconThem and it's "named icons" instead of custom Stock items, but has not quite been completed. One tricky aspect is that in order to manage a set of images for one icon at different sizes, it is still handy to place them into a stock object to hold them. However referencing them is not via stock ids, but rather name ids (which are different API calls for gtk widgets that use icons)

The main "gotcha" or shortcoming is that the named icons of GtkIconTheme use physical size only, and not logical size. As themes are loaded and changed, sizes also change so may cause issues.

XDG Base Directory Specification

The XDG Base Directory Specification lists how to identify sets of directories to use as base points for asset and file loading and storage.

GLib has supported this for some time, and among other things this allows an end user to switch config for applications at launch time, with the equivalent of an unlimited number of parallel installs with no conflicts and custom non-overlapping settings.

Specifically to issues of icons, the documentation for g_get_user_data_dir() states:

Returns a base directory in which to access application data such as icons that is customized for a particular user.

One easily overlooked but critical aspect is that often users are not allowed to install things such as themes under /usr/, etc. In these cases installing into a user owned directory is an absolute must.

Themable Application-specific Icons

Themable Application-specific Icons is a new proposed approach to allow for themeable icons specific to themselves without file and packaging conflicts.

One key item to note is that this is a separate/additional step to the base GTK technical solutions of Themeable Stock Icons and named icons.

Another point to consider is that the "${prefix}/share/<appname>" aspect of locations should be expanded in compliance with the XDG Base Directory Specification.

References

Also see ApplicationIcons