hicolor icon theme clarifications
dobey at novell.com
Wed Jun 9 04:34:10 EEST 2004
On Hën , 2004-06-07 at 20:36 +0300, Tommi Komulainen wrote:
> I've been figuring out how exactly applications are meant to be adding
> their icons in the hicolor icon theme as (very shortly) described in
> Now, that leaves some essential things open, in my opinion.
> 1. Which directories are guaranteed to exist?
> As I've understood it, the directories need to be mentioned in
> the index.theme for the icons to be found. The only directory
> that is explicitly mentioned is 48x48/apps, which I suppose will
> exist, but that's somewhat ambiguous.
Right. In fact, it may not be guaranteed that the hicolor theme even
exists. So, you might install icons, and they still won't show up. And
to boot, there is no good way to determine if the theme does exist,
other than probing some directories, which isn't reliable either, and
you will also still have to parse the index.theme yourself to see if you
even have the directories you are installing to, available to the theme.
And since one can have multiple index.theme files across the filesystem,
in order to provide overrides, etc..., this is pretty much not worth the
trouble of doing currently. Unfortunately, gnome-icon-theme tries to be
smart by checking the filesystem for hicolor/index.theme in a specific
set of directories, and installs a bunch of icons into hicolor. I think
there is also a separate "hicolor" theme that actually contains icons,
and used to be the old KDE default theme style, which could cause even
more pain for people trying to install stuff into the hicolor theme
> "Optionally you can install icons in different sizes" but unless
> those sizes are included in index.theme, it'll be pretty
> useless. And modifying the index.theme during 'make install'
> doesn't sound too good, either.
Indeed. This is definately not the right way to go. We really need to
fix the issues with the spec and the implementations, and get a standard
naming scheme for creating icons. I hope we can do it soon.
> 2. What are the naming conventions and rules for filenames?
There aren't any really. What does get used, has basically evolved from
what applications were written to use before icon themes existed, and
from what artists decided to name some icons when they created them.
It's not a pretty thing, really. I've sent several mails to this list in
an attempt to get discussion how to fix this. Please see those.
> Can I simply install a '48x48/apps/browser.png' file, or are
> there some rules I should be aware of?
Ideally, anything you are installing into the "hicolor" theme will have
a very distinguishable name. Something like "my-silly-app.png" for
example. If every web browser out there, ships "browser.png", and
installs the default into "hicolor", then we're in for a bit of a mess.
Unfortunately, this is a harder problem to solve, than I would like,
though there are some adjustments to the spec that can be done to
assist in preventing problems where multiple apps try to install the
same icon into hicolor. Namely, not having apps install things to
hicolor, and fixing things up in the implementations with regards to
fallbacks and dependencies.
> Where am I supposed to put application-specific toolbar icons
> and such? Are there some naming conventions to follow?
If the application is using the icon theme for those icons, then the
naming conventions are that of the application, unfortunately. We really
need to get a standardized naming scheme worked out for this stuff.
> Can I install any file in '*/stock/*' or should they be prefixed
> with 'stock_' or something?
They don't have to be. I'm not sure why they are, even. It doesn't
really make sense to duplicate things like this. Yet another thing
that will be fixed by standardizing icon names...
> How are mimetype icons be named?
MIME type icons are named gnome-mime-foo-bar in Gnome. I am not sure
what they are named like in KDE. See my other mail(s) where I provided
a list of about 300 icon names that we can standardize on for all
desktops. I would like more actual discussion on those, but it looks
as if that isn't going to happen. If some discusson doesn't start soon,
I'm just going to start implementing a standard, and that will be that.
> Forgive me if some of this isn't on-topic, it's not so clear where
> freedesktop ends and gnome begins.
This is off-topic, at least, with regards to this mail. But, yes, it is
blurry in some places. The Shared MIME Info spec is also a bit blurry
between the lines of FD.org and ROX. The Icon Theme Spec was written,
based on what KDE was already attempting to do, and so the line there
is blurred as well. Now we're left with a bit of a messy situation in
some cases, where the specs are slightly more biased to a specific
desktop, because of where most of the bits came from. I hope to at
least fix the icon theme spec to be better, as well as get the
standardized naming scheme for icons into place, so that we can actually
share them between desktops. I also need to hit Thomas Leonard on the
head for the comment in the shared MIME info spec, about how MIME type
icons should be named.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040608/16091a7e/attachment.pgp
More information about the xdg