Icon theme spec on the website

[Rodney Dawes]

On Thu, 2008-09-25 at 21:05 +0200, Jakob Petsovits wrote:
> And a staging area. Like, a place where developers can list their icons 
> regardless of applicability in other desktops, and other devs list theirs too, 
> and everyone can have a look at what similar applications use and consequently 
> agree on a single naming set.

You mean like the "Missing Icons List" and "Additional Icons" bits on
the icon-naming-spec wiki page [1]? I think Diana Fong created these a
while back, but they never went anywhere, because she left Red Hat, and
nobody else ever pays attention to the wiki. It's obvious you didn't
look there, for example. And I can't force people to use it.

> I believe a major problem is that the desktops just don't know of each other, 
> and use whatever non-standard icon names they can just think of, even if the 
> other desktop has already done lots of thinking about this issue and might 
> have a sounder solution. If we want people to work together on icons, we 
> should know what the other's icons are and how they can be made to fit into a 
> single scheme. And when people agree on a given name and description, they 
> should go into the spec.

I don't think it's a real problem. The whole purpose of the spec was to
solve this. And I think it's doing fairly well now. KDE 3.5 was
obviously a big problem here, but nobody ever wanted to change it to
follow the spec, because everyone was waiting for KDE 4.

> I wanted to throw up a website to facilitate this for a long time, but it just 
> never fit into my schedule. Maybe someone likes the idea and feels motivated 
> to help the devs come together for icon naming and more detailed usage 
> descriptions :]

See the wiki which we already have. All you need to do is use it, and
get other people to use it. This stuff needs to happen on
freedesktop.org, not on kde.org or somewhere else.

> I also believe that an icon naming specification should not aim to have 
> developers rethink how their application works, which is what dobey also tried 
> to do with the spec. How interfaces are designed is subject to a given desktop 
> and its user interface paradigms and HIG, trying to force a specific way of 
> working onto the other desktop is imho something that slowed down icon 
> adoption.

No, it's not what I tried to do with the spec. I tried to facilitate the
lowest common denominator. If some desktop really thinks they need to
provide significantly more icons in the base theme, and that any theme
designed for that desktop needs to provide those icons as well, there is
nothing preventing that from occurring. But such requirements are not a
part of this spec, and are the responsibility of the desktop. The spec
provides guidelines for naming those icons, and hopefully those icon
names will be derived from ones in the spec, facilitating the fallback
mechanism which is described there.

What slowed adoption of the naming spec in KDE was several developers
and users conflating the icon naming spec, and the tango icon theme, as
well as the fact that nobody wanted to change KDE 3.5, and instead were
working on other aspects of KDE 4 than icons at the time.

> Anyways, let it be bottom-up, not top-down. Desktops and applications use 
> their own icons anyways (if they can find artists drawing those, at least), 
> and won't stop doing so just because the extremely limited set of icons in the 
> spec doesn't cater to their needs. We should try to find similarities where 
> those already exist, and only cut down on icons when a solution can be reached 
> that everyone is comfortable with.

Again, as I've said several times. The naming spec is the lowest common
denominator, and the minimal set of icons a theme should provide. Adding
ever possible icon that does exist, or may exist in the future, is just
not plausible, if we ever want to call it a 1.0 spec. What can be done,
however, is for more specific icons, suited to more specific
applications, to be defined in addendum specifications, such as the
device names addendum which I have mentioned several times.

> My opinion is that a fixed set of icon definitions will never suffice for all 
> the different usages there are. Let the icon naming spec be replaced a 
> publicly editable list of which icons exist and where / how often those are 
> used. Themers do one icon at the time anyways, so they could just pick the 
> next one on such a priority list until they lose motivation (one could also 
> say "until they're done", but complete icon sets covering all desktops and 
> applications don't exist and are mostly a utopian wish, imho).

No. A fixed set will never suffice. And you will never finish writing a
set of icon names if all you ever want to do is make a list of icon
names that could possibly be shared across multiple applications.
We don't need to replace the spec. We need to either get me more time to
work on the spec, and creating addendum specs, by somehow employing me
to do so, or you need to get people to get off their own asses and help
out. Demanding icons be added by me, is not help. There is no such thing
as having a priority list that anyone can edit and set the priorities
on. At that point, it's just a list, and an overly large and exhausting
one at that. The Icon Naming Specification *is* the priority list.

> Unfortunately I'm away from desktop tinkering for quite a while still, so I 
> can't help with that effort. However, please do feel encouraged to pull up an 
> inclusive working ground as opposed to a minimal static list, I'd welcome an 
> effort to get the people to work together again instead of begging the spec 
> maintainer for something they won't get anyways without lots and lots and more 
> lots of discussions that are mostly going nowhere.

Like I said. The wiki is there. The spec provides guidelines for naming
icons. And it's always been the goal to create addendum to the spec for
additional icon names for specific applications such as Devices,
Developer Tools, Graphics Tools, etc... So just start helping. There's
nothing stopping anyone from doing it, except for themselves.

Thanks,
Rodney