Multiple DeskTops, HiColor theme, standardized icon names, & menu icons

[Rodney Dawes]

Hi,

Sorry for the slow reply. I was on vacation last week, and have been a
bit busy this week.

On Tue, 2006-06-06 at 08:11 -0700, James Richard Tyrer wrote:
> We need a common place to install menu icons (i.e. "apps" icons).

We have one. The hicolor icon theme is where app icons are to be
installed. This is specified in the Icon Theme Specification, and the
information about the apps context in the Icon Naming Specification
clears this up a bit, in terms of how to name the icons.

> Since all icon themes are not complete, we need fall back icon themes
> (note I do mean themes, not just *a* theme).

I disagree. Each desktop needs to provide its default theme, and needs
to fall back to it, immediately before hicolor. We did this for GNOME
2.14, by implementing a new XSetting in GTK+ to specify the default
theme, so that icons will work outside of GNOME, as gnome-icon-theme no
longer installs icons to the hicolor theme. The XSetting for this is
called "Net/FallbackIconTheme".

> It has been proposed that we have standardized icon names.  Is this
> really a good idea?  By standard names it is meant that different
> DeskTops will have the same name for icons with the same function.  The
> purpose of this appears to be so that apps from different DeskTops will
> have a similar look when being run together on the same DeskTop.

The purpose is so that themes will actually work across all desktops,
without having to have multiple copies of the exact same icon, simply
because some developer chose to use a different name than some other
developer, that are both writing the same kind of app.

> I see a problem here as others have correctly pointed out.
> 
> I note that "apps" icons are not going to be a large part of this
> problem since they should always have distinct names -- apps should have
> a distinct name for their menu icon.  However, even here there can be a
> problem if DeskTops install their own icons for popular apps.

Desktops that want to override the app icons that are installed to
hicolor should do so by providing those icons in a theme for the
desktop, not by installing to hicolor. Installing anything to hicolor
other than app icons, should be considered a bug in the software that
does so, and a failure to comply with the Icon Theme Spec. I realize
that the section about installing icons to hicolor isn't particularly
clear, but the spec was written with the purpose of sharing app icons
across desktops, and was not originally designed to deal with full blown
themes. 

> This is not an easy issue to solve.  What come to mind first is to have 
> separate: "hicolor" directories for each DeskTop:
> 
> 	hicolor.kde
> 	hicolor.gnome
> 	hicolor.xfce
> 	hicolor.<etc>
> 
> and one for third party apps:
> 
> 	hicolor
> 
> {This probably shouldn't be considered a real solution but rather just 
> an example to illustrate the problem.}

The real problem here is that we need a good way to deal with
action/status/etc... icons provided by the applications themselves,
which are not part of the base set of icons, or are specific to the
application itself, and are required by its UI. Application icons
themselves shouldn't be an issue, as they should be installed to
hicolor. 

We really need some way for apps to install icons into a private theme
directory, and specify that lookups should be made within it, as a
fallback. One hacky way to do this currently, is to install icons into
a private data directory, in the "hicolor" theme, such as:

/usr/share/application/icons/hicolor/

One can then alter the XDG_DATA_DIRS variable internally to the
application, to include /usr/share/application/ within the path. This
will cause this instance of icons in hicolor to only be used within the
application in question, and avoid file conflicts with other
applications which may want to install an icon of the same name.

Having a somewhat more sane method to do this, would be much better
though, I think. And, we certainly need one.

-- dobey