Icon Name Standardization, second draft

[Rodney Dawes]

On Thu, 2005-03-31 at 21:01 -0500, Andrew Conkling wrote:
> On Thu, 2005-03-31 at 14:57 -0500, Rodney Dawes wrote:
> > Aliasing really belongs in the Icon Theme and MIME Type specifications
> > themselves, rather than in the Icon Naming Specification, I think. The
> > aliases aren't there to say that something should be named some way.
> > They should be meant to allow theme authors to create one image, and
> > specify legacy names for that icon, that apps may still use, so that
> > we don't have to copy icons around or create symlink farms, to make the
> > desktop look proper when using the theme. I will be working on a patch
> > to the Icon Theme spec, and to gtk+ as well, for implementation value,
> > to do something like Provides=foo,bar for the .icon files.
> 
> I didn't realize there were two specs. ;)

There are multiple specs. I believe the Shared MIME Info spec takes care
of allowing aliases for MIME type definitions. The Icon Theme spec needs
something similar for icons.

> > One of the purposes of this spec, is to list all the generic icon names,
> > as well as many of the more specific names. However, I am not sure how
> > best to distinguish the two, in the docbook source for the spec.
> 
> Generic being the designated name and specific being legacy names?  If
> that, we could just add a column on that list and name it "Provides
> these legacy icons" or something.  Just like you're suggesting to add
> to .icon files.

No. Generic is the generic name, and specific is the specific name. For
instance, "printer-remote" is generic, while "printer-remote-smb" is
more specific. "printer-remote-smb-hp" would be even more specific.
Legacy icon names are something we want to get rid of entirely. The
fallback to more generic names, is something we should devise a nice
implementation spec for doing, along with some standard aliases, I
think. Anyway, I will be working on a proposal for aliasing in the Icon
Theme specification, soon.

> > If this is happening in GNOME, then it is a regression, and you should
> > file a bug report. The panel used to have code to strip the extension
> > and path off of an icon's filename in the desktop files, for looking up
> > in the icon theme. If no icon was found in the theme, it would fall back
> > to trying to use the full path as specified in the file. I'm not sure
> > what KDE does here, though.
> 
> Nope, Xfce here.  That Gnome slickness, though, seems a bit of a
> workaround; I think something should be laid down in a spec to settle
> the affair (when I say this in bugreports for my distro, they never know
> about this) so one could refer to it for a description etc.

Ah. I suppose we need to add something about this to the Icon Theme spec
as well, then.

> > I recently sent a seperate specification docbook file to xdg list, but
> > it seems to be still waiting for moderator approval, as the docbook is
> > slightly above 40K in size. Jakub had pointed out a couple things, so
> > perhaps I will make those fixes, and send it out again, compressed, or
> > on a web server somewhere.
> 
> So what can I do at the moment to help?

I'm not sure. The first draft is still stuck in the moderator queue I
guess. I've sent a second, compressed version, with the fixes from Jakub
just now. Read over it and reply to that thread, I guess. :)

-- dobey