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

[Owen Taylor]

On Fri, 2003-06-27 at 10:56, Thomas Leonard wrote:
> On Thu, Jun 26, 2003 at 03:19:22PM -0400, Owen Taylor wrote:
> > On Thu, 2003-06-26 at 08:46, Thomas Leonard wrote:
> [...]
> > > 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.
> 
> Well, should it be an icon theme? Things like size lookup, theme thumbnail
> and i18n from the icon spec sound useful. Then again, I could use
> Jonathan's suggestion of /usr/share/themes/<name>/icon, which makes a lot
> of sense (ie, slightly rework 'icon' to fit in to the themes system).

I really don't understand why you think that MIME icons are something
different than application icons, toolkit icons, and in fact the MIME
icons that GNOME and KDE use currently. All of which are handled by the
icon theme spec right now.

All we need is a little hookup between the MIME spec and the icon
theme spec and we are all set.

> > 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.
> 
> Sounds good. So there would be a 'Net/MimeTheme' key, for example?

Net/IconTheme

> > > (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.
> 
> There's still the 'Context=MimeTypes' bit. That won't work if you lump
> everything in together. Besides, we have an application called
> 'mime-editor'...

Context is used only for user selection of icons, not for automated
lookup.

> [...]
> > > 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?
> 
> Well, you can't use a GNOME theme as the default, because that would
> upset KDE, and you can't use a KDE theme for the default because that
> would upset GNOME, so I'm guessing it's going to be a fallback theme that
> noone really uses or wants to spend much effort on, but has to be there
> just in case.

There are definitely are issues there. And frankly, the question
of default icons is the big unresolved issue in the icon theme spec.
Right now, the default GNOME theme will *not* pick up the application
icon for any application in KDE CVS.

But it seems clear to me that any 3rd party application icons, whether
app icons or MIME types need to go into the default theme.

> > Saying that the default theme has to be smaller than any conceivable
> > icon theme someone wants to create seems like an unreasonable
> > restriction.
> 
> Probably. I suppose people might want to extend the GNOME theme rather
> than the default, so you get the same problems anyway.

People have to be brow-beaten into extending the default theme. One
reason that you need to extend the default theme is that the KDE
folks don't have a published name for their default theme so
you can't install icons into it.

(It's 'crystalsvg' today, but AFAIK it could be something else
tomorrow.)

> > 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.
> 
> It's very difficult to know what the correct behaviour is there. Gimp must
> feel that a generic 'image' icon isn't good enough to represent xcf files, 
> but should a theme that doesn't know anything about xcf files be able to
> override that?
> 
> > > 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.
> 
> I was thinking that we'd get theme authors to provide an icon for each
> catagory. If theme authors could provide an icon for 'Sound sample',
> 'Sheet music', etc catagories then it's much less likely that you'd want
> to override the icon for particular subformats.

I don't know. People seem to like having icons for particular
subformats... I don't know if preventing that make sense.

Regards,
						Owen