XDG Icon Spec: requesting new icons for headsets, speakers, headphones

[Rodney Dawes]

On Thu, 2009-05-14 at 11:30 -0500, Ted Gould wrote:
> No, I think the problem is that people disagree about what the purpose
> of the spec is.
> 
>         You clearly believe that it's a way to force applications
>         towards a certain design principle.

Not really. People just like to somehow imagine this perception, because
I also care about usability as well as icons.

>         Other folks seem to see it as a way for applications that want
>         to express the same thing to agree on a name for what that thing
>         is.

Other folks seem to want it to be a list of whatever icons they think
they need. Different applications have always used the same icons for
different meanings, and they continue to do so, which is why we have
also wanted to add metaphor descriptions to the spec as well. However,
having every single icon that every single developer wants, in one
single list, is not the scope of the spec.

> Personally, I think that all we can do is hope for the second option and
> encourage collaboration on those names.  The reality is that pushing
> design guidelines between to visually diverse projects (not including
> all the subprojects using the spec) will simply result in failure.  I
> guess I'll reword your statement from Ken:

The truth is pure and simple. The Icon Naming Specification is and
always has been the base set of icons which all other icon names may
fall back to. And it has always been a given that GNOME and KDE have
different default themes, which may provide more icons than in the spec,
which may also fall back upon before falling to hicolor. The Icon Theme
spec and the Icon Naming spec, are both written in a way to allow this,
and to allow for icon names above and beyond what are in the spec.

>         [the spec should] not wish to involve [itself] in suggesting to
>         developers possibly better ways to present UI to the user, but
>         rather simply wants to [specify] the icons

The spec does not involve itself in suggesting to developers better ways
to present UI to the user. I think that is pretty clear with the entire
lack of any UI description in the spec. The spec contains names, how to
create names not in the spec, and some metaphors.

> I would say that design guidelines are more appropriately placed in
> something like a HIG than the icon naming specification.

I totally agree. And the icon naming specification does not have
anything in it about UI design and layout.

My making suggestions to developers for better ways to present UI to
users is purely external to this specification. It is something I do in
my facilitation of the role as a GNOME developer, and maintainer of the
gnome-icon-theme and Tango. However, people like to somehow conflate
these activities into one thing, when they disagree with anything I
say or do. And that is inappropriate.

It's also a pure and simple fact that requiring icon theme artists to
draw 5000 icons in at least 5 different sizes to have a complete theme
is utterly insane. I've also started icontool [1] to help with some of
the problems here. Currently it consists of the rendering script we've
been using for single-canvas icons in Tango, GNOME, and other projects,
and the bits of icon-naming-utils to create backwards compat symlinks.
I intend to at some point also provide other useful tools as well, such
as lintian checks for SVGs, SVG compositing tools to generate additional
icons with using parts from different SVGs, and other similar scripts.

However, as I have several times over, I am not opposed to adding new
icons to the spec that make sense and have reasonable feedback and
support for getting them in, with proper naming. I also don't want to
add icons that have a high potential of being removed or unused in the
short/forseeable future. And I'm not going to add icons where there is
no real consensus or discussion on them, outside of myself and the one
other person that proposed them. It doesn't make sense to me.

I'm trying to encourage collaboration and I want other people involved
in the process, but it's fairly evident that nobody really cares, or
they'd be taking part in the discussion themselves. And I can't go
around trying to find every related party for an icon proposal. For most
icons, to be able to define a consistent metaphor across desktops, we
need to know where and how it will be used. This is not suggesting
alternate design, it is simple basic design fact. Either we need to know
this to define metaphors in the specification, or we need to just avoid
defining metaphors, so every desktop can have completely different icons
if they want and nobody can argue about it because there's no
specification. Early on, there was some consensus that we could define
consistent metaphors in the spec as well, for the icon names, so that
KDE and GNOME would also have the same metaphors, and could look less
out of places when running an app from one environment under the other.
If that's not what people want to do, then that needs to be clarified,
and I will happily update the spec to remove references for defining
metaphors for icons. If we want to have consistent metaphors, then we
need to have more collaboration and work on defining those as well as
icon names.

But I don't wish to do any of these things in the spec without a
somewhat general consensus. I want the spec, and all the desktops
using to all be awesome, but that's not going to happen when people
would rather have trifle flamewars than provide useful feedback and
discussion on the matters at hand. And the obvious broad misconception
by the same people isn't helping with that, but I don't know how to
fix their misconceptions, and get them to collaborate in a reasonable
manner.