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

[Owen Taylor]

On Thu, 2003-06-26 at 08:46, Thomas Leonard wrote:
> On Wed, Jun 25, 2003 at 10:09:38AM -0400, Owen Taylor wrote:
> > On Wed, 2003-06-25 at 06:16, Thomas Leonard wrote:
> [...]
> > > 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.
> 
> This seems a bit problematic for 'metathemes', then, if there's no plan
> to migrate everything one way or the other. 

A bit annoying, but only requires just a tiny bit of unpacking 
intelligence.

> Given that the MIME stuff
> doesn't have any legacy issues to worry about, I'm just trying to decide
> which system is preferred for new themes. Perhaps the icon spec could
> mention something about this?

If it's not an Icon theme, put it in /usr/share/themes. If it is an
icon theme, I don't see why it needs to be different than the
icon theme spec.

> Also, there needs to be a way to specify what the current theme actually
> is (we should allow for using one theme for application icons and another
> for MIME types, but whatever themes are chosen, they should apply to all
> programs regardless of desktop).

The current GNOME metatheme concept is that a metatheme is a set of
setting for different theme types, rather than a single theme name
that applies to everything. This seems to work quite well ... I like
the way that the gnome-theme-manager worked out.

Yes, there should be some way of specifying the current icon theme.
In the GTK+/GNOME world this is clearly a XSETTING, and I'll be 
doing that for GTK+-2.4, but I just haven't had the bandwidth to push
XSETTINGS as a cross-desktop thing.

> > (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.
> 
> Won't this also cause incompatibilities (at least as far as ~/.icons is
> concerned... ~/.local/share/icons)?
> 
> It seems there are a lot of compatibility issues here. Not that ~/.themes
> is any better in this regard.

I haven't looked into the issues with the base directory spec.

> [...]
> > 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.
> 
> OK, : sounds good to me then.
> 
> >  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)
> 
> (mime/text.png?) What can it collide with? There shouldn't be anything
> except MIME icons in the directory, surely?

Only icon names are used in lookup according to the icon theme
spec; The directory part is just organizational.

> > 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. 
> 
> >  WeakAlias=mime-audio
> 
> What about just not including multiple audio/* types in the default theme?
> The default theme is supposed to be really minimal, and having all your
> audio files look alike isn't a disaster.

Is the default theme supposed to be really minimal? Why? Saying
that the default theme has to be smaller than any conceivable 
icon theme someone wants to create seems like an unreasonable
restriction.

Note that any application with a custom file format is likely
to install an icon for that format into the default iocn theme. 
E.g., the GIMP would install an icon for image/xcf into the
default icon theme.

> Another possibility would be to introduce catagories for MIME types (eg,
> spreadsheet, wordprocessor, musical score, etc). Some of the MIME
> groupings (particularly application/*) are really bad for icons.
> 
> GNOME's 'File Types and Programs' config tool seems to have this all set
> up already. Should this be added to the MIME spec?

If you think that you can get people to agree on the groupings, it 
might be useful. But it would also require something like WeakAlias.

Regards,
						Owen