Icon theme specification and multiple parents problem.
alvarezp at alvarezp.ods.org
Sun Feb 10 04:12:51 PST 2008
Hi, I haven't found an answer to my question so far in the list
archives, so please excuse me if this is has been discussed already.
The Icon Theme Specification allows defines an Inherits key as follows:
"The name of the theme that this theme inherits from. If an icon name is
not found in the current theme, it is searched for in the inherited
theme (and recursively in all the inherited themes). If no theme is
specified implementations are required to add the "hicolor" theme to the
inheritance tree. An implementation may optionally add other default
themes in between the last specified theme and the hicolor theme."
Even though the spec looks is clear enough, the following scenario
somewhat bothers me: Say we are looking for the file "weird-func.png"
and have the following themes.
1. "slightly-modified-distro-theme" theme. No "weird-func.png". Inherits
from "specific-theme1, specific-theme2".
2. "specific-theme1" theme. No "weird-func.png". Inherits from
3. "specific-theme2" theme. It has a generic somewhat similar
"weird-func.png" to the design of theme #1. Inherits from
4. "universal-distro-theme" theme. No "weird-func.png". Inherits from
5. "universal-desktop-theme" theme. It has a generic desktop-related
"weird-func.png" file. No more parents.
6. "hicolor" theme. It has an unthemed "weird-func.png".
What bothers me is that, according to the specification,
"universal-desktop-theme" will be checked *before* "specific-theme2",
which is more likely to have compatible looks with the main theme if the
file exists, than universal-desktop-theme, which is 3-levels away.
Shouldn't the spec let the search to go level by level? This is, from
all immediate parents first without inheritance and then all
second-level parents and so on, checking "hicolor" at the very end?
More information about the xdg