Icon Name Standardization, second draft

[Rodney Dawes]

On Sat, 2005-03-26 at 03:20 +0000, Frans Englich wrote:

> They are not required to create them. All they need is to inherit from a theme 
> to get full coverage. What's important to understand is that if an icon is 
> required by one application, at least one version of the icon exists. 
> Otherwise the application doesn't function, and the requirement would have 
> been left out.

No. Inheritence currently means that all the more specific icons from
parent themes will show up, if your theme doesn't have them. And if
you're theme doesn't match the style of the parent themes, then you end
up with mix and match icons. This makes the system look horrible and
very amateur. We want to move away from this behavior, and have generic
icons that themes provide, that are preferred over more specific icons
from the parent themes.

> Why I think a concept of optional name-sets won't work, is that from the 
> application perspective icons can't be optional -- if they're missing the 
> application breaks. Hence, for a distribution to in a general way provide 
> icons for arbitrary applications, they must ship somekind of "large base 
> theme" -- and that's what specialized themes inherits and overrides, and 
> hence simply fallbacks to un-themed icons when specialized/rare areas are 
> entered. And in that way artists don't have to create full themes, only what 
> they want to cover.

You're confusing fallback to parent themes and optional icons with
fallback to generic icons in the selected theme. As I stated above,
we want to get the latter working, so we can get rid of the behavior
of the former.

> I see two reasons to why it should be "separate":
> 
> * A semantic distinction. I wouldn't understand why; afterall, the current 
> specification deals with names(prefixes, paths) already. If this is not about 
> icon themes, what is it then?
> 
> * A matter of reading convenience, that the specification becomes a too large 
> page. This was mentioned in the previous discussions, and which I agreed to 
> and suggested turning on chunking of the Docbook sources. We can do that.
> 
> Why do you want to have it separately?

Becuase it's not the same thing, it's large and only going to get
larger, and the same people didn't write it, and aren't maintaining it.

> It is neither meant to be a mechanism for looking up icons(unfortuantely), so 
> it can't fail in that area. That's why the names have prefixes. The draft 
> namely contains a clarification on this:
> 
> "The Context allows the designer to group icons on a conceptual level. It 
> doesn't act as a namespace in the file system, such that icons can have 
> identical names, but allows implementations to categorize and sort by it, for 
> example."

> Why? Personally, I stay neutral. What you say is that for example KDE should 
> deprecate certain functionality, and that KDE have that functionality is not 
> justified. What is wrong with that it "allows implementations to categorize 
> and sort by it"?

I'm saying that Context is useless, not that KDE should deprecate
certain functionality. What functionality are you even going on about
here? You said yourself that Context is not used in the lookup of icons,
so I don't see how getting rid of it all together will deprecate, or
make unjust in the KDE API.

> I wouldn't discuss its validness, but keep it to not break backwards 
> compability as well as avoid conflict with those who like it, and simply 
> namespace the names(doing lookups by something more than just filename brings 
> anyway complications).

I'm not claiming whether it is valid or not. I'm simply stating that it
provides not functional value currently, and that my opinion is we
should either add the functional value, or remove it completely.
Removing it means that there is much less to type in the index.theme
file. Making it have functional value in looking up icons, allows you to
have icons of the same filename across multiple contexts, so that you
don't have to do as much namespacing. This also makes creating themes
somewhat simpler.

> I've found "file system" icons a tricky area too. I see two problems with 
> using a MIME-name pattern for "file system"-related icons(except for /real/ 
> MIME types of course):
> 
> * MIME types have a technical meaning. When a MIME name is used solely as icon 
> name, then we have opened up to a name clash with an actual MIME type. Hence, 
> AFAICT, if an icon should be named as a MIME type, an actual MIME type should 
> exist for it(registered, or informally), in order to avoid trouble.

Huh? x-directory/normal isn't a MIME type? Last I checked, it was.
Anything displayed in the file manager, and existing on the filesystem,
has a MIME type of some sort. I don't know what naming clash you're
talking about. There isn't one.

> * Some icons doesn't fit into the MIME concept, AFAICT. An icon for a MIME 
> type represents a media, identifies a passive /object/. However, an icon for 
> the /action/ "encrypt file" is far from a MIME type, but still file system 
> related. file system != MIME.

"Encrypt File" should be in the "Actions" context then, not in the
"FileSystem" context. And it probably shouldn't be specific to low level
file operations. If it is a verb, it belongs in "Actions".

> While "american spelling" surely gives an instruction on how to judge in 
> certain cases, it does not cover what Posix C locale outlines. It's a 
> different thing(such as character set). But, regardless of if the guidelines 
> becomes internal or part of the specification, this needs a deeper 
> discussion(reference to Posix C locale, spelling conventions etc).

We should specify the en_US.US-ASCII locale. This covers the problem of
spelling, as well as character set.

> (as stated above, the prefix cannot be stripped). But I'll add a Categories 
> context in next draft.

Stated above where? I don't see why "category-" must be a prefix for an
icon name that describes a category.

> A set of generic guidelines which would make it possible to not have a 
> name-set and that people could independently figure out indentical names 
> would of course be preferred. I have no idea how that would be phrased, feel 
> free to write/explain.

We must provide some level of implementation. However, that does not
mean we can't provide general guidelines for adding new icon names. We
might only specify "drive-harddisk" as a minimal requirement for themes,
but we probably want to allow "drive-harddisk-ieee1394" as well.

> I know Andrew Conkling will comment in a couple of days, but after that and 
> this thread have bounced back and forth or so, I'll prepare the next draft.

Well, hopefully he will reply soon. I look forward to his comments as
well. However, I am going to be writing up a full formal spec draft, and
posting it here, which is based upon the minimal list of icon names that
I came up with after discussing the list with Jakub, to finalize the
minimal list.

-- dobey