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

[Rodney Dawes]

On Thu, 2009-05-14 at 16:08 -0700, Brian J. Tarricone wrote:
> 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.

Then again, if the spec is a list of well known names used in lots of
places, it probably doesn't make sense to stick icon names in there that
only one app and one developer uses. It's not that I'm not going to
proceed, but if I can't get a reasonable discussion out of the person
proposing, and nobody else is joining in to provide that reasonable
discussion, then there isn't too much I can do. And when I notice that
something is a mistake from the original write-up of the spec, and I
suggest changing it, and aligning the newly recommended names along with
that change, and all I get "you can't make that change, it should be
done this way" then there isn't much I can do with that either. If I go
ahead and make those changes, and the person proposing the new icons
continues using the names they asked for, rather than the ones added to
the spec, then what's the point? Sometimes, there just needs to be
a couple more people providing input, to avoid those situations.

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

And that's fine. I don't know a whole lot about them either. That's why
I ask the questions I ask. I want to increase my knowledge, so that I
can perhaps take in the request, and make other recommendations, and so
that others who decide to join the conversation, will have more
information about the request and what it entails. I don't see why some
people think this is a problem. But alas.

> 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 don't even know how one would draw an icon of a 'handsfree' device
that you don't wear. Technically speaking, my computers are 'handsfree'
devices, as I don't need to use my hands to have a skype call with
someone. And I think we at least did reach consensus that 'handsfree'
doesn't make much sense for an icon. 

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

Right. That was my point. You didn't care before. When the flames lit
up, you started caring. How many others just don't care? If nobody
cares enough to write when the flames aren't there, then how do we get
the people who should care, to do so? And why don't they care now?

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

Right. Icon themes are odd in that you can't really have 'one'
implementation of it. In any implementation you must have the code that
references the icon names, and you must have the theme that provides
them. Most developers don't draw icons, and most artists don't write
code. So we need to somehow strike a reasonable balance between those
two parties, and not overwork one, with demands from the other.

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

The spec doesn't prevent people from shipping icons in their
applications. And it doesn't prevent people from theming those icons in
their themes. There's no requirement in the spec that an icon must be in
the spec to use it in your app. If there were, I suppose we wouldn't
have any app icons, because the spec would need to list every single app
that could appear in the menus. And that's a bit unreasonable to expect
such a requirement. Why can't a developer include the icons they need,
in an application-private hicolor theme, as many applications do btw,
and then say "Hey. We're using these icons for blah. We think they might
make sense for other applications to use as well. What do you think of
adding them to the spec, and do you have any recommendations on their
naming? Thanks." to recommend them for the spec? Much nicer than "We use
these icons. Put them in the spec. kthxbye." don't you think?

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

Like I said before. No. I don't reject them. Either I get no further
responses from the requester, or I ask questions, and the requester
gets pissed and just drops it for no apparent reason, or I ask
questions, the requester disagrees, doesn't provide any useful counter
arguments, and nobody else gets involved, and we are at an impasse.
There isn't much I can do for people with silly tempers, or that just
outright disagree and don't provide reasonable alternate suggestions.
And so, here we are.

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

Perhaps, but I think Tyra is too busy to maintain the spec. But she's a
bit high strung anyway, so probably would be off-putting once people
actually tried to chat with her about it. I don't know why others don't
get involved. They sure don't tell me why. All I know is that we need
to get them involved in the discussion somehow. If they don't know how,
that's fine. It means we obviously need to communicate that better
somehow. Part of the problem may also be that some people, for whatever
reason, see the spec as Tango and/or GNOME pushing some agenda on the
rest of the world, despite how hard I've tried to keep the spec separate
from them. If I'd wrote the spec as a maintainer of Oxygen or Crystal or
various bits of KDE, I would have worked just as hard to get KDE to
adopt it faster, as I did with GNOME. If someone in the KDE camp cares
enough, and has a little time, and the ability to have reasonable and
rational discussion on the subject, I am more than happy to have that
person help in coordinating discussion for these recommendations, and
furthering adoption and participation in the spec. As it stands, I do
support both desktops in various ways. I even lurk in #oxygen to provide
the artists there with icon naming help, and even recommendations for
icon design and metaphors.

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

Yes. I could do that, but as I said in response above, it doesn't really
make sense to just go ahead and do something, if the requester outright
disagrees and isn't going to use the names in the spec, even if I add
them, albeit slightly differently to how they requested them. And so, I
think that is a point where we need another party or two to help further
the discussion.

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

Well, since nobody is actually saying anything about any real problems,
and instead are just making suggestions of forking the spec, or looking
for some way to insult me, it's certainly coming out as whining, whether
or not that's the intent. If people really think there are problems,
then they should I don't know, perhaps e-mail me off the list first,
and articulate them in a respectful way. Saying "Hey asshole. Why don't
you put my icons in? We should fork the spec, because the current
maintainer is a pain in the ass to deal with." is not respectful or
even remotely helpful to the situation.

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

They probably don't join the discussions, to avoid dealing with the
flames like this. And some of them just want to draw icons, though they
prefer knowing what to draw, rather than digging in random directories
to figure it out, and then having to copy files into those directories
to get the icons to work. I know most of them don't want to have to
draw every icon under the sun either though. I've gotten lots of thanks
from various artists for taking the initiative to create this spec,
and deal with the annoyances of maintaining it, over the years. It's
unfortunate that I don't get some similar appreciation from the other
side of the table. But I trudge on, and try to do what I can, and help
maintain some semblance of balance. 

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

Exactly. And if I'm not entirely sure about the details, and the people
that might be, don't want to tell me what those details are, because
they think they're unimportant in their code, then there isn't much I
can do with that lack of information. It's like trying to ask a floor
salesman at Best Buy which wifi chipset a laptop on display is using.
It's just going to go anywhere.

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

No. I'm not saying it is acceptable. But failing to provide more
feedback, and then simply asking if I'm going to add the icons, isn't
acceptable either. It's a bit rhetorical at that point. I want to add
some of the names, but the organization needs to be fleshed out more.
If the requester doesn't want to help provide the information needed
to get that done, and nobody else jumps in though, it's going to have
to sit on the back burner until I have time to concentrate on it. I
don't get paid to maintain the spec. It's not my day job. It's something
I do, because I enjoy working with free software, I care about icons
and the desktops, and I don't always have the time I would like to have,
to work on it. The general lack of discussion about the spec on the
list, also leads me to believe that nobody else is willing to put forth
the time I have, to help out with the spec. That means, however
unfortunate that it is, that sometimes requests might end up on the back
burner too long, or that things may not happen as fast as we wish them
to. But complaining about it isn't helpful either.

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

Certainly. And that's what the devices section of the spec is meant to
do. Have the base device classes as names, with branded specific icons
branching off those base classes. 

> > 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 how do you think I feel when they simply ignore the questions I ask,
which are meant to get the information needed to fulfill the request in
a reasonable manner? The problem goes both ways here. It's not just me.

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

I suspect mostly because people think that vision is something that it
isn't, they don't know what it is, they don't understand it, or they
haven't bothered asking about it. Of course, I've talked about where I'd
like to see the spec go, and all that, in various forums. And I don't
think any of that conflicts with needs of developers and artists who
would use the spec. And I'm not sure of any better ways to communicate
that. Some people just won't listen anyway. :(

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

Neither is preferable. The preferred outcome is to of course get
reasonable names with a reasonable hierarchy now. And that is the
course I'm trying to maintain. But it is hard when developers are
uncooperative. :(

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

I don't know how many lurk on this list any more. None chimed in for
this or the original request discussion, no. It's also a bit difficult
to get real opinions on the matter out of them. The Tango artists, will
generally just defer to me on the question of naming, anyway. I think
pinhero would defer similarly if he were asked about the names. In this
specific case for the audio icons, it would probably be more beneficial
to get feedback from perhaps developers of other sound servers,
particularly the KDE audio guys. Or also perhaps from some other audio
app developers, such as Ardour, or from some VoIP app developers, like
Skype. Although, the Skype guys probably just don't give a damn really.
But these are the types of apps where I could see such audio device
icons being used in a useful way. And being generally involved with
audio, they might have more/better input about the hierarchical
organization of the different audio device types. Then we could probably
have some real consensus on the names, and get the icons in the spec
more quickly.

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

I don't think a wiki is the solution. Currently it's very easy to make
a patch against a single text file. If it were in a git repo, would that
be better?

> > 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 don't know that sticking the existing names in a wiki somewhere is the
best course of action. Perhaps getting a couple people to create (or
update) a pending requests page, and help spark some discussion about
the particular icons there, with appropriate people, would be a good
start though. And perhaps moving the spec, and device-names.txt both
to a common git repo, would be helpful as well? I hate git, but if it
will get more people involved in the spec, and discussing the various
issues and whatnot, I'll do it.

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

Perhaps. I think Launchpad's Bugs would be very useful for this. It's a
lot less cumbersome than bugzilla, and has a neat REST API, though of
course it's not running on fd.o. Perhaps a few of us could hack up a
quick django app in python to do this? I don't know how well we could
integrate it into the freedesktop user db, and such, but shouldn't be
too difficult to get a basic site up and running either. Though if it
had a nice REST API too, that would be best, because I hate having to
do so much in a web browser. I already have a desktop. I don't need
another one inside it. :)