Mime Icons and weak aliases (was Re: Theme meme)

[Owen Taylor]

On Wed, 2003-06-25 at 06:16, Thomas Leonard wrote:
> On Tue, Jun 24, 2003 at 12:58:31PM -0400, Owen Taylor wrote:
> > On Tue, 2003-06-24 at 07:17, Thomas Leonard wrote:
> > > On Sun, May 04, 2003 at 01:40:14AM -0400, Havoc Pennington wrote:
> > > [...]
> > > > The low-hanging fruit is a "metatheme" spec (GNOME has a setup for
> > > > this which I believe is essentially identical to the icon theme spec
> > > > which is in turn basically same as KDE icon themes - could be
> > > > documented and banged into shape probably).
> > > 
> > > What's the current status of the theme spec? I'd like to use a theme-based
> > > system for MIME icons in ROX-Filer, but the icons spec only mentions MIME
> > > types as a future possibility.
> > > 
> > > I'd imaging there would be something like ~/.themes/MyTheme/MIME-icons/...
> > > with the various icons named after the MIME types, possibly in various
> > > sizes. Sharing MIME icons wasn't possible in the past, due to there being
> > > no agreement on what the MIME type names actually were, but using the new
> > > MIME spec that problem should go away.
> > 
> > I'd think MIME icons should simply be built on top of the icon theme
> > spec, instead of being somthing different.
> 
> What's the relationship between the 'icon theme' spec and the 'metatheme'
> spec? Where does ~/.themes fit into this?
> 
> Is ~/.icons replacing ~/.themes, or the other way round? Will ~/.icons
> contain GTK themes in the future?

The reason that /usr/share/icons/ThemeName is not
/usr/share/themes/ThemeName/icons is basically legacy. KDE was already
using /usr/share/icons/ThemeName, and it didn't seem worth changing.
(Not everybody agrees with this, but I suspect a change is unlikely
at this point.)

Certainly ~/.icons will *not* replace ~/.themes for GTK+ themes.

(Though we unfortunately still have major incompatibility in the icon
theme spec between desktops because you can't find KDE icons without
knowing the magic KDE default icon theme name, currently crystalsvg.
But anyways...)

> Also, is the icon theme spec going to use the base dir spec?

I'd assume so.

> > E.g, you say that the icon
> > for mime type a-b/c-d is the icon called "a-b:c-d" or something like
> > that.
> 
> Sounds fine. Perhaps someone could add it?
> 
> (the spec gives mime_text_plain as an example, but the leading mime_ seems
> unnecessary)

The leading mime prefix seems sort of nice to me, but the use of _ to
replace / isn't going to work since according to to RFC 2045, media
types like x-stuff_stuff/x-more_stuff are legal.

The set of characters you can't have in a media type token are:

"(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="

Of these, ':' strikes me as the best replacement for '/'. 
(';' has the possibility of confusion with mime type
parameter lists)

My suggestion is:

 mime-text:plain 

with
 
 mime-text

being the fallback if type:subtype isn't found. (That's why
the mime- prefix is nice. 'text' has too much possibility
of collision)

But we really need to have some agreement from KDE before adding 
that to the icon theme spec. The current ways GNOME and KDE handle it
are:

 GNOME: gnome-mime-audio-x-wav, gnome-mime-audio
 KDE: Icon name is specified in the .desktop file along with other
      information about the mime type

There is one issue with the fallback system that I was discussing
with Alex recently that might require further changes to the icon
theme spec ... the issue is that say the default theme includes
icons for a dozen different audio/ subtypes. 

An icon theme artists might want to use a single icon for all of them.
Currently, they would have to create a big nest of symlinks and
hope that no *more* audio/* subtypes were added to the default
theme.

My idea to fix this was adding the idea of a 'weak alias' to the
icon theme spec. In the default themes mime-audio:x-wav.icon you
would have:

 WeakAlias=mime-audio

Which means: 
  
 If you find this icon in this theme, do another lookup on 
 'mime-audio' and if you find it earlier in the derivation stack,
 use that instead.

(Better name than WeakAlias? There is some vague analogy to weak
aliases in ELF, but the analogy is *far* from exact.)

Regards,
						Owen