Icon Name Standardization, second draft

[Frans Englich]

On Saturday 26 March 2005 22:57, Rodney Dawes wrote:
> 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.

Exactly.

> 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.

If the meaning of "optional" has become that if they're abscent, they get 
mapped to a generic icon in the currrent theme, then it's a different thing 
-- which I certainly like.

I've suggested a couple of times on the xdg-list a concept, to me hard to 
distinguish from your "intra-theme-fallback" mechanism, dubbed "pseudo 
icons", which allows the theme author to map "pseudo" names to actual 
icons(conceptually similar to symlinks). Here's some links(food for thought):

First mentioning, although slightly wrong in problem analysis(the 
introduction):
http://lists.freedesktop.org/pipermail/xdg/2004-July/004232.html

In relation to emoticons:
http://lists.freedesktop.org/archives/xdg/2005-January/005680.html

In relation to implementation(GTK's binary index cache):
http://lists.freedesktop.org/pipermail/xdg/2004-October/005186.html

See also the first draft(has a good discussion, IIRC).

However, I gave up on it because there was too low interest from implementors, 
but perhaps that can change(currently, I see the two mechanisms, your's and 
the 'pseudo'-one, as roughly similar, until we plunge deeper into it).

We would also be able to cover emoticons with the icon theme with something 
like that(currently it's going in the direction of a separate theme with XML 
files and what not).

[...]
> > Why do you want to have it separately?
[keep icon names outside the icon theme specification]
>
> 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.

I don't see how who wrote and who that maintains have anything to do with it. 
What do you mean by larger? If we want to split the source files, we can do 
that anyway we want; if we want to split the exported XHTML, we also got full 
freedom.

>
> > 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? 

How my draft describes it essentially, IIRC Alexander have also described on 
the xdg-list why it's in the spec. If it becomes truly necessary I'll find a 
way to provide a screenshot from KDE, but any dialog which allows the user to 
select an icon, allows the selection of a category(context) from a drop-down 
which then shows those icons, instead of showing all icons.

The problem is that if it's removed from the theme, that information does not 
any longer exists, and it's simply impossible to group icons by context(since 
it's gone!).

[snip MIME]

> > 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.

Yes, good idea.

>
> > (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.

Since you can't namespace icons on the filesystem level by their Context, a 
removal of a prefix raises the likelyhood of clashes. Of course you can 
remove it, but then it's a question of valuating whether it will lead to 
clashes or not. I rather give icons prefix, than estimating what the future 
will be like(now assuming no other mechanism will provide a namespace 
facility).

>
> > 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.

Ok, I still don't understand how two independent, isolated, developers can for 
an arbitary icon figure out identical names in a detereministic way, but I 
perhaps will when it's more concretely put.

>
> > 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.

Could we put this in a broader context? We've had two big drafts on this lists 
-- with positive feedbacks and discussions -- and what happens now is a 
second effort is started, not being built upon the current, AFAICT.

In the letter you reply to, I mention I will prepare a third draft, from the 
continued discussions and feedback. Could we coordinate, say describe how 
your ideas relate to the current on going work, such that energy and time 
isn't wasted? I'm not interested in something in the direction of 
competing/paralell efforts.

Also, we may have different views on this, when coming from different 
backgrounds. I don't "shove some random" icons around, or "going on about" , 
because you might think so. We have different views on this, and we simply 
need to sort that out.


Cheers,

		Frans