Brian J. Tarricone
bjt23 at cornell.edu
Mon Jul 16 17:26:08 PDT 2007
James Richard Tyrer wrote:
> Brian J. Tarricone wrote:
>> Not to sound flippant or dismissive, but... who cares?
> You do sound flippant and dismissive. :-D
Being flippant and dismissive would have been saying "who cares" and
leaving it at that ^_~.
>> It's already how it is, so why make extra work for something that's
>> purely an implementation detail that end-users won't see anyway?
> As a retired EE, I have to tell you that your attitude is not conducive
> to a standards making process.
Extensive "bike-shed"-esque discussions over piddling details aren't
particularly conducive to a standards-making process either.
Regardless, I'd hardly want to compare the IEEE/ISO/ECMA/etc. standards
processes with what goes on here (which is what I assume you're talking
about after profession-dropping).
> And please note that on KDE that users
> do see the names of the icons every time they select an icon.
(This section is a little OT, I guess.)
That sounds like an unfortunate implementation to me, then. Look at the
rest of the icon names -- do they look like they should be user-visible?
IMO, they shouldn't be. Especially when you consider some proposed
extensions, e.g. the proposal for device-specific icons
(multimedia-player-ipod-mini, multimedia-player-ipod, multimedia-player,
These names should be hidden from the user and replaced with general,
*localised* descriptions where possible. Or, perhaps, the names
shouldn't be shown at all. The point of the icon selection is the icon,
not the name, right?
Actually, given that KDE displays icon names to users, what would make
more sense to your typical end-user? 'emblem-link-symbolic', or
'emblem-symbolic-link'? I'd say the latter: people generally don't
>> If it's necessary to expand the use of emblem-symbolic-link for other
>> types of links, this can be noted in the description in the icon
>> naming spec.
> This is version 0.8. This means that it is expected that changes will
> be made before 1.0 is released.
True, but there are already implementations relying on it. I'm not
saying that means things that need to change shouldn't change -- I just
don't think this is something that needs to change. Or, to put it a
different way: what harm would there be in leaving it as-is that would
justify the work required on various parties to update their applications?
> I listed two proper ways to do this -- ways that comply with the spec.
> If you think that the current name is correct, and that my suggestions
> do not follow the spec, then please comment on that.
Ok, so what other links do we have that might require an icon
representation? Off the top of my head, I can only think of one:
URL/network links, which don't appear to have an icon name(?).
Say we have, emblem-url-link (or emblem-link-url). Are symbolic links
and URL links naturally 'descendants' of a 'link' type? I'm not sure.
On one hand, they're both 'links' in that they're pointers to some kind
of other location, and you can put them in an arbitrary location, and
they'll (usually) still be valid and point to the thing that they link to.
On the other hand: symlinks are always local, and are usually
represented by a filesystem-locale path name. Symlinks are an actual
file system object: you can actually have a symlink on your disk. ou
can't have an URL link on your disk. URL links usually point to a
resource that is not local, may not be available all the time, and
usually will require special software to access (well, with KDE, you
guys have a swiss-army-knife file manager that does just about
everything, but I'd consider that the exception, not the rule).
So I guess it's a bit murky to me whether -symbolic-link or
-link-symbolic is more correct. Since I don't see either one as being
clearly correct, my original opinion stands: leave it alone.
More information about the xdg