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

[Rodney Dawes]

On Fri, 2009-05-15 at 00:56 +0200, Lennart Poettering wrote:
> On Thu, 14.05.09 17:51, Rodney Dawes (dobey.pwns at gmail.com) wrote:
> 
> > 
> > On Thu, 2009-05-14 at 11:55 -0700, Brian J. Tarricone wrote:
> > > > and has been for a long while now. And the base spec clearly identifies
> > > > how to name these device icons anyway, for specific types of devices,
> > > > with only the base types being in the base spec, so everything falls
> > > > back to those base types.
> > > 
> > > Except clearly the list is incomplete and there are other device types 
> > > (like speakers and headsets) that you hadn't thought of.  This list 
> > > doesn't help Lennart's case.
> > 
> > That's fine. But when I make suggestions and the original proposer tells
> > me "no that doesn't make sense" and no one else is involved in that
> > discussion, there's obviously an impasse. Telling me that hierarchy
> > doesn't matter, when the entire point of the Icon Naming spec is the
> > hierarchy, is also not helpful to the cause of getting the names added.
> 
> I guess you are the only one around who sees the "entire point" of the
> Icon Naming spec in the hierarchy. Most other people think the point
> of the spec is more that is is a somewhat agreed on vocabulary of
> welll known icon names. That's all.

The base spec (docbook bit in cvs) is supposed to primarily be the 'root
node' of that hierarchy. But those are also well known names. It is
meant to be something that provides the base set, and provides for
extensibility to allow theme authors and desktops to provide additional
icons on top of that base set. The more specific names generally should
be put in addenda. As there are so many potential icon names, though, we
also really need a searchable index some place. Simply listing every
icon in a single table isn't very usable. Perhaps we could build a
simple index and web interface for searching. And the result information
could provide the data about the preferred metaphor, whether the icon is
part of an addendum or in the base spec, and other related information.
With a simple REST API as well, we could tie this search into different
UI design apps, or development environments, to make it easy for
developers to look up such information.

> It has certain advantages if there is a hierarchy in those names, but
> that's not more than a technical detail that eases resolving in some
> cases.

Yes, but because it's a technical detail doesn't mean it should be
ignored, and that it doesn't affect the organization of the icons in the
spec. It may not be as important when you are writing your code and want
to load an icon, because that bit is handled automatically by the
toolkit for the most part, but it is important for placing new icon
names into the specification. Because I ask for more details and make
differing suggestions, isn't because I'm stalling, or I hate you. It's
because I want to understand what the best hierarchy is, for putting the
names in the spec. I'm all for getting some of these in the spec, as I
think it would be nice to have different headset icons in some places,
where it makes sense.