emblem-symbolic-link

[Brian J. Tarricone]

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

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

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

	-brian