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

[Brian J. Tarricone]

Rodney Dawes wrote:
> On Thu, 2009-05-14 at 11:55 -0700, Brian J. Tarricone wrote:

> No. I never actually denied these icons, or specifically stated they
> were a bad idea. I asked questions about how they would be used, and
> what they are, and how to organize them, and to get other people to
> comment. No one else commented. And I was told the organization isn't
> important. In fact, I very recently added an icon to the spec. But I
> guess it doesn't matter because it wasn't /your/ icon, right?

If no one else comments, it may just mean they don't know.  It may mean 
they don't care.  In the absence of anything else, you have a fairly 
prominent developer with a problem and a way to solve it.  So what do 
you do?  You can either accept what the developer wants, or you can just 
  put up a seemingly-impenetrable wall of "I don't understand the use 
case so I'm not going to proceed."  You can't always get consensus and 
advice from other parties.

(For the record, I've never asked for an icon to be added to the spec. 
Though I suppose you could be using "your" in the generic sense there.)

>>> If you can't wait, then get off your asses and do something to help.
>> That's exactly what people are trying to do here, but it's unclear as to 
>> how to proceed because of your involvement.
> 
> I have made it very clear several times how to proceed. We need more
> people discussing these things. This thread was dead until everyone
> started to flame me. Why weren't you involved in the original
> discussion?

I told you: I don't know anything about sound systems.  But since you 
asked, here's my uninformed opinion on the specific case:

I think 'audio-card', 'audio-speakers', and 'audio-headphones' make 
sense based on Lennart's definition.

As for -headset and -handsfree, I'm not sure.  They both serve a similar 
function (vocal audio input plus audio output), but, physically, they're 
very different devices.  Maybe one should be a sub-type of the other, 
e.g. audio-handsfree for the separate device, and 
audio-handsfree-headset for the wearable kind?  I dunno.  They don't 
seem to 'degrade' reasonably to me; if there's no -handsfree-headset 
variant in the theme, the user might be a big confused to see an icon 
depicting a non-wearable handsfree device.  But the reverse is also true 
with -headset as the parent and -headset-handsfree (which language-wise 
doesn't even make sense) as the specialisation.

Maybe a hybrid approach?  -handsfree as a generic type, and then 
-handsfree-headset for headsets and -handsfree-something as the 
non-wearable device?  Of course then that means three icons instead of 
two, and the "required" one (-handsfree) doesn't really have a good 
definition.

I dunno; kinda at a loss.  Personally I'd probably just give up and add 
both -headset and -handsfree.  Bluetooth actually has separate device 
classes for "headset" and "handsfree device" (and I believe some devices 
may report that they support both) so it would be beneficial to require 
different visual representations.  It would look weird to have two icons 
the same for two different device types (even if the devices are similar).

Ok, so I guess I do have an opinion after all.  But that's not really 
the point.  At the time of the original discussion, I didn't care enough 
to spend the 5-7 minutes I just did thinking about it.  It's not my 
problem space.

> Where are your comments about the suggestions I made, and
> the questions I asked? From this end, all I see is people looking for
> some excuse to bitch and argue. And neither of those is particularly
> productive. Either you don't care about the icons in the first place, or
> you involve yourself in the discussion and try to help get a meaningful
> resolution. Waiting until the flames start broiling isn't helpful.

Why did I jump in now?  Honestly, I'm not sure, and frankly I'm somewhat 
regretting my first email.  Not because I no longer believe what I said 
to be true (I still do), but just because I don't care enough to put 
this much time an energy into this discussion.  But since I hate 
starting something and not following up... here I am, still.

>> Guess what?  The "goals of the specification" (whatever the hell that 
>> means; inanimate documents don't have goals) are irrelevant.  The needs 
>> of the community and of the people who will use the specification are 
>> paramount.
> 
> If it's irrelevant, then obviously the entire point of freedesktop.org
> is irrelevant. Developers aren't the only ones with needs.

How does that follow?  If th specs on fd.o reflect the needs of the 
people who use and implement the specs, and the end users who use 
software that implement the specifications, then it's successful.

>>> In short, no I have no problems adding icons to the spec.
 >>
>> Then add the icons that people think are necessary rather than 
>> stonewalling at just about every single request.
> 
> I will when it makes sense to do so. Demanding I do so is not going to
> get it done. I've said that before, and it remains. We need proper
> consensus, not demands.

How do you get proper consensus for something where only one person 
seems to be working on a particular problem and needs icons for it? 
Just because there's only *currently* a single implementation that needs 
them doesn't mean others won't.  Sure, that's pretty subjective, but I'd 
be rather surprised if KDE doesn't have (or intend to have) some sort of 
bluetooth management app.  While that doesn't necessarily follow that 
they'd want device-type-specific icons in their UI, it isn't 
unreasonable to assume that they might.

>>> But I won't go
>>> adding every single icon, that every single developer asks for, with the
>>> blind hope that it makes sense in the spec.
 >>
>> You're not adding every single icon.  From my on-and-off observations 
>> over the past couple years, you add very few icons.  It's too 
>> conservative, at least according to sentiment expressed here.  You can 
>> either respond to what the community needs, or you can blindly push 
>> forward with your own agenda that no one really cares about and doesn't 
>> actually help developers and artists *in the real world*.  Too bad 
>> you've taken the latter choice.
> 
> There have been very few proposals for new icons. Don't blame me for
> lack of participation by others.

So instead of rejecting most proposals out of a list of 100, you reject 
most proposals out of a list of 10.  So what?

>>> It's funny how nobody really
>>> wanted to get involved in the discussion for suggested icon additions to
>>> the spec, but everyone comes out of the woodwork when it's time to
>>> insult the maintainer.
 >>
>> No, everyone comes out of the woodwork when they realise that there's a 
>> systematic problem.
> 
> Doesn't look that way to me. Just looks like everyone wants to complain
> about something they're not involved in at all in the first place.

I'm scratching my head over this, but I'm not really sure what to say. 
I could say "no one get involved because they don't know how."  But then 
you'll just say "I need more people commenting on icon addition 
proposals."  I think many people see you as the gatekeeper of the spec, 
and -- despite what you've asked for -- believe that their opinions 
don't matter all that much.  Maybe that's just my perception.  If it's 
not, and it's true, I'm not sure how to change that.  The fact remains 
that you are the sole and final gatekeeper in this.  Maybe that's 
off-putting to some people, regardless?

> I have no problem adding the icons, but they need be organized properly
> and have proper names. And 2 people going back and forth saying "i think
> this is better" and "no i think this is better" isn't going to get that
> done.

No, but at some point you have to sit back and say, "we're not making 
forward progress here.  Since I genuinely do believe these icons should 
go in, even if I'm not sure I understand the organizational aspects, to 
make progress it might be best to defer to the person who works with 
this stuff all the time."  If you didn't want that type of icon in the 
spec at all (just as a for-instance), and had a good reason, then sure, 
that's fine.  No-full-stop.  But you do seem to think the audio-* icons 
are a good idea, so it seems like when you get stuck on the details it 
might be better to just do the best you can rather than just stopping 
dead.  But I suppose that's how I look at things and others (like you) 
might prefer to attack the problem differently.

>> How can you say that?  Look at this thread and the number of responses. 
>>   Sure, some of it is potentially unjustified whining, but you get that 
>> with any discussion about stuff people care about.
> 
> Because the majority of this thread is unjustified whining. And it's all
> due to nobody being involved in the discussion, and therefore the
> discussion falling by the wayside.

No, you're right.  The thread now is more about "why the current 
management of the spec isn't working for us" than about Lennart's 
request.  Whether or not it's all unjustified whining... well, I don't 
happen to think so, but that's certainly a matter of opinion.

>>> We really need to have feedback from multiple app developers, and
>>> artists both, for icons to go into the spec. There needs to be some
>>> balance between what developers think they need, and how much we can
>>> expect any theme artist to draw. And we need those people to understand
>>> the goals of the spec, which this thread has made it abundantly obvious
>>> as being a problem.
 >>
>> No, the problem is that the goals of the spec don't fit what the 
>> developers need.  I won't speak for artists because I don't know what 
>> they need.  Perhaps some artists could speak up?  Currently the balance 
>> is "the artists don't need to do anything because none of the developers 
>> can get new icons in the spec."  How is that useful?
> 
> Now, that is bullshit. The "community" isn't just developers.

You'll note that I specifically mentioned artists as well.  But they 
don't seem to speak up when new icon requests come in, either.

> And apps
> always need icons regardless if they are in the spec or not. But putting
> every icon for every app in the spec DOES NOT make sense. At that point,
> it is no longer a spec. It is merely a never ending list of file names.

Certainly.  *App* icons shouldn't go in there.  But it's hard to argue 
against most infrastructure-related icons (like bluetooth control), 
since you have a built-in audience of "any desktop environment developer 
who wants to make XYZ hardware setup not impossible for their users." 
But as you've already stated, you aren't against these icons; you just 
aren't sure about the details.

>>> If one doesn't have the patience to endure the
>>> process of time, and can't get artists and other developers that might
>>> use the same icons, to get involved in the discussion, then I fail to
>>> see how a lack of consensus is a problem that being disrespectful, and
>>> demanding, is going to solve.
 >>
>> Basically this lack of consensus involves you on one side, and everyone 
>> else on the other side.  At least, I haven't heard anyone else chime in 
>> in support of denying Lennart's request.
> 
> I didn't deny it. I said I need more feedback. I don't want to put names
> in and then in 2 months rename them all again because they make sense in
> a different organization. No one chimed in to say either for or against.
> The problem is that you, and apparently no one else either, wants to
> discuss the issues. You just want a vote for in/out and be done with it.
> That's not how specs get written.

Ok, you did ask for more feedback.  But... as I've already pointed out, 
there wasn't more feedback.  So we're left at an impasse.  A reasonable 
request for which the foundation was good, but the details weren't quite 
hammered out to your satisfaction, gets dropped on the floor.  That's 
not really an acceptable situation.

> What do you think *real* developers are? And what do you consider a
> "complete" icon theme here? If complete means every icon ever used by
> any application that might get installed on my desktop, then no one will
> ever be able to create a complete theme. So it's obvious that there
> needs to be some balance. One way we can do that is to have a unified
> set of icons that wouldn't need to be redrawn for every desktop, as we
> do now. I've talked with David Vignoni and Ken Wimer a bit about this at
> the last UDS in Mountain View, and we all agreed that sharing a bunch of
> the redundant icons would be beneficial for both desktops. Of particular
> note are device icons, such as all the iPods and the like.

Heh, I don't think anyone can actually define a "complete" icon theme. 
Or if they can, I'm sure we can come up with 5 other people with 
different definitions.  It's not going to be complete in the sense that 
it covers every single icon that shows up in every single application. 
But I'd hope we can agree that *at least* the stuff relating to hardware 
and hardware types (at least stuff that isn't horribly rare or decades 
obsolete) is reasonable for the spec.

>>> [1] http://www.tigert.com/2005/09/15/ive-created-a-monster/
 >>
>> I don't really agree with the thesis here.  For me, icons are a mental 
>> shortcut so I don't have to always read text.  They have nothing to do 
>> with differentiating between important or unimportant options.
> 
> Yes. I don't agree 100% with it, but the overall title and concept I
> totally agree with. When every button and menu item have icons, you lose
> the effect of what icons are meant to provide. When you open an app that
> has a list of documents or windows, and every icon is exactly the same,
> or only slightly different, that mental shortcut is gone, and you have
> to read the text anyway.

Agreed.  If the icons aren't distinct, they're pointless.

>> If you've found any of this personally insulting or disrespectful, 
>> please point out what parts and I'll be happy to apologise.  It's not my 
>> intent to be insulting, just to try to get the point across that there's 
>> a huge disconnect between your vision for the spec and what people here 
>> actually need.
> 
> Some of it does seem to be. Accusing me of not doing /any/ work, when I
> in fact have,

Yes, I'm sorry about that.  That was clearly not true.

> and stating that I only ever deny requests, which I don't
> even tend to do. The lack of things going in, is not due to denial. It
> is the lack of requests and feedback to make sure things are correct
> now, rather than revising the spec and making everyone else change there
> code all the time, because the spec keeps changing.

But the end result is effectively the same.  If you don't deny a 
request, but don't make progress on it either, because you aren't 
satisfied with the level of feedback (which isn't going to come), then 
that state looks pretty much the same as denying it.  Except it's almost 
worse, because the original requester feels like they're left in limbo.

> And the bit about
> suggesting a personal agenda. I only want our desktops to be the best
> ever.

I think I just chose my words poorly.  Everyone has a personal agenda, 
and that's fine.  I didn't mean that in the nefarious "he has a secret 
ulterior motive" sense... more just in that you have a personal vision 
for how the spec should be managed and what it should cover.  Many here 
seem to disagree with how that works.

>> What would *you* suggest to help fix this situation?  It seems like 
>> people want more icons in the spec, or at least more icon names 
>> acknowledged as being used in the field such that they should be 
>> included in icon theme implementations.  Should we start another list of 
>> icons as someone else suggested?  Should we try to flesh out your 
>> device-names.txt list with more concrete examples, and put it somewhere 
>> where it's easier for people to add to when they come across new model 
>> numbers, or when people need new classes of devices?
> 
> I think we obviously need more collaboration and communication, and we
> need it from more than one person sticking an icon in their app because
> they think it should have on there. We need people developing similar
> apps on other desktops to provide feedback in the discussion.

Well, that presents a bit of a problem.  To go back to this specific 
case, what if no one else has a bluetooth config/status/enumeration app 
(I'm not saying this is the case; I really just don't know)?  What if no 
one gets around to writing one for the next year?  Should Lennart name 
the icons whatever he pleases and include copies with his app, and then 
revisit the issue in a year?  Of course, during that time, maybe no 
artists are interested in drawing themed versions of his icons.  And 
maybe after the issue gets revisited when there are more 
implementations, we find that the icons are named differently across 
implementations, and now it's harder to agree on the final set of 
names... and regardless, when a decision *is* made, everyone has to 
change their software, plus probably keep in a fallback with the old 
icon names (and possibly with fallback copies of icons using the old 
names) until the icon themes catch up.  How is that preferable to making 
a -- perhaps imperfect -- decision now?

> We need
> artists to provide feedback on what they think is too much to have in
> the base set, and what they feel is a good balance.

Sure!  Where are they?  I know some of them lurk on this list, but I 
don't believe any chimed in during this discussion (or Lennart's 
original discussion).

> The device-names.txt
> file could certainly have more examples in it.

Ok, but, as I said, it's not very public, and a .txt file in your 
personal web directory makes it difficult for anyone but you to add 
examples.  Maybe it could be put on a wiki somewhere?  (Or maybe there's 
a better option... I hate making it sound like wikis are the solution to 
  all the world's problems.)

> We also need people to
> help flesh out what's needed for other addenda as well, such as emotes,
> mime types, and actions. New classes of devices belong in the icon
> naming spec. The device-names.txt is for listing specific model
> examples. I'm also willing to move the icon naming spec, and the various
> addenda into a git repo for the icon naming spec. Of course, that
> depends on someone setting up the repo so I can move them over. We've
> also got wiki pages, that I don't think anyone is actively using. Diana
> Fong, who used to be at Red Hat, had started setting up wiki pages with
> icon names and info, as a sort of status for requests, but that sort of
> went nowhere as she left Red Hat, and no one else really got involved
> in it. (There were some icons in Echo that she wanted to get names in
> for, iirc.) I would be glad to see something like that happening again,
> but I don't have the time to maintain it as well. But if yourself, and
> others want to do so, I would definitely support it.

Cool!  And yeah, I guess that's the problem... finding someone with both 
the time and inclination to maintain it.  I'm not that person.  But 
maybe the first step is to cut and paste device-names.txt into a wiki 
page on fd.o somewhere.  That's not that hard.  Would you be ok with 
that?  I'd even be willing to do that much if you think it makes sense.

> I definitely need help managing the requests and the discussions for
> their inclusion. A mailing list probably isn't the best place for it,
> either. We sort of need something where we can show status for
> individual icon names, and have a record of comments in support of,
> or against, including specific icons, and what they are used for,
> and how, and all that.

Hmm, so something like a specialised form of bug tracker?  I dunno, this 
isn't really my area of expertise.

> So let's stop bickering about this and get things rolling in a manner
> that will benefit everyone.

Good idea ^_^.

	-brian