Generic Fallback

For the concept of icon themes to work, theme authors need to have a very essential set of icons to target. Specific device and mimetype icons shouldn't be required to be covered for a theme to feel visually consistent. A theme author should only have to worry about designing a few generic icons that would take precedence over specific icons from the inherited theme (It is more important to be visually consistent rather than cover a specific mimetype or device icon).

the Problem

The current fallback mechanism is based on namespacing in the icon filename. If a specific icon isn't returned, the last part of the icon name is removed and the lookup is repeated. So for example if camera-photo-nikon-coolpix doesn't exist, camera-photo-nikon is looked up, and if that fails camera-photo is being looked up (which is defined in the name spec as a fallback icon). Note that even if camera-photo-nikon-coolpix would exist in the inherited theme, it is not preferred to the generic icon from the current theme.

Sadly this method doesn't work well for mimetypes. In most cases mimetypes don't follow this stucture. FIXME: examples of related filetypes having completely different mimetypes

Possible Solutions

A generic mimetype icon would include a metadata file (.icon) which lists all the specific mimetypes it can be used for.