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

[Thomas Leonard]

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

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

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

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

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

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

But I think we'd need to write down some examples of possible conflicts
and what our ideal system would do in each case.


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk		tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1