mime-type icons, a proposal

[Rodney Dawes]

On Tue, 2004-09-28 at 09:32 +0200, Alexander Larsson wrote:
> Of course you can't have "neutral" icons that matches all icon themes. I
> don't see why forcing app authors to draw multiple icons for what
> happens to be the current default for various desktops helps with this.
> If we force people to do this, its extremely likely they'd just copy the
> same icons into these themes anyway.

So it wouldn't be any different than now really, except we would put the
burden on the author, rather than the icon theme implementation. The
main issue here is the application icon itself. And, really, we
shouldn't use a theme as a dumping ground for random app icons. It
sucks. So, as I said, we need to rethink some parts of the spec quite
a bit more at some point. However, given the number of other problems,
and the fact that most applications do in fact not install their icons
into the hicolor icon theme, I think it can wait until we fix some of
the other issues.

> hicolor is currently the only thing actually shared between desktops. If
> you remove this, then the icon theme "standard" will be even more of a
> joke, actually sharing nothing at all between desktops. It'd be nothing
> at all different from gnome and kde having totally different systems.
> For instance, an installed kde app wouldn't get an icon in the gnome
> panel menu unless the kde app specially installed a gnome icon (which is
> unlikely).

Hicolor is also the only theme that doesn't actually theme anything.
It's just a dumping ground for suggesting others to throw their icons
in. The icon theme spec was based primarily on the way KDE icon themes
were already working, and was designed primarily for sharing application
menu icons across desktops. This is where the problem is. The suggested
fallback theme is hicolor, because that is what the default KDE theme
used to be. Though, now it just has no icons in it, and was redesigned
to be a dumping ground for those application menu icons. I don't see how
changing the lowest level fallback suggestion to not be there, when it
has no icons in it anyway, will cause problems. The fact that it's the
lowest level theme in the tree, is the only thing actually shared by
desktops. The only thing I can think of that installs icons to it, is
gnome-icon-theme, and that is only because for some reason we need to
put them there to guarantee that we have certain stock icons available
when themes other than "gnome" are in use. And since the icon names
aren't standardized, the likelihood of them showing up in another
desktop is slim to null.

> We *must* have a common location that *both* kde and gnome and any other
> implementation of things like the desktop file spec look for icons, or
> apps won't be able to install app icons that work on all
> implementations. This is non-negotiable. 

Sure. Just like we need a common location for installing desktop files
that adhere to the menu spec, or for installing mime type definitions.
However, menu entries and mime type definitions aren't designed to
provide a consistent look and feel across the desktop, whereas a theme
is. I totally agree that we need a common location, I just disagree
that it should be a theme.

> Ehhhhh? I think you missed the point about this rule.
> 
> This rule is to avoid a huge performance penalty. See e.g. rmls recent
> text about why reading many small files is extremely bad. Just because
> it is wrapped in a library doesn't mean the app doesn't actually do it. 

I didn't miss the point. I was agreeing and stating that if what we
currently have is broken, we should fix it, rather than designing a
whole new API that does the same thing, only somewhat less expensively,
while still having to keep the old code around, for ABI/API compat
rules. Your rule basically just specifies how the backend code should
work. But whatever, implementation abstraction details don't belong on
this list really. 

> Adding "mime" to the filename does make it avoid conflicts with other
> icons in an icon theme that e.g. apps use in a desktop file or whatever.
> The fact that mime icons are in a subdirectory has no affect whatsoever
> on the way icons are looked up. Its merely a way for theme authors to
> have some structure on their files. The icon namespace is a global non-
> hierarchical namespace. 

Then what exactly is the "Context" attribute for? Isn't it there for
specifying what particular icon you want in a specific context, so that
you get the correct version of there are multiple icons at the same
size, but in different directories? Also, if we specify a standardized
naming scheme for icons, the chance of conflict is greatly reduced. An
application which doesn't specify the correct context for an icon, when
doing a lookup, would be buggy, no?

> I think a user would prefer a generic spreadsheet icon for a gnumeric
> file instead of a "category-unknown" icon. This is not some contrived
> situation either! A new theme would start by doing the generic type
> icons, such as spreadsheet, and this would immediately cause all
> spreadsheet type mimetypes to use that icon. One could later add a
> gnumeric-specific one, but many theme authors probably wouldn't add
> specific icons for all sorts of mimetypes.

Sure. Let's come up with a list of all the "generic" types and work
something out then. I just didn't understand what you meant by the
current method being a disaster. Though, I think we will have the
standard third-party being unwilling problem here, since we will be
requiring the mime definition file to specify the generic icon, since
third parties would generally prefer to have their icon shown. At which
point, we also can't just specify a list ourselves, because not all
specific types may be known, for association with the generic type. Will
we fall back to "current method" before going on to "app-specific" at
this point?

> I'm aware of your list of icon names. However, by now all the desktops
> using the icon theme spec already has lots of apps using their current
> icon names, and lots of themes using them. Changing this is gonna be
> very very hard. Thats just the way things are. Deciding on the list of
> common icon names to use is just a small part of doing a change like
> this.

And the longer we put it off, the more icon names they will be using
that will be vastly different from all the other desktops, and on and
on. I don't care if it's hard or not. It's enough of a disturbance to
me, that I'm willing to change it. And there are plenty of tools which
will make it significantly easier than without. If we can get consensus
on the names, then we at least have somewhere to start.

> > > Some people will not like this proposal. In particular, people from
> > > real will probably not like that they have to provide many themed icons,
> > > and that they can't get a real-specific icons into all themes
> > > automatically. However, I think its a pretty good compromise that
> > > allows real to install real-specific icons while still allowing theme
> > > designers some level of control of how their themes look.
> > 
> > I think it's a pretty solid proposal, but needs a little bit of thinking
> > in some respects. I'm sure the artists will love it when we can give
> > them a standard definition of icon names and such. Maybe myself, you,
> > and others can get together at the Gnome Summit and hash this out
> > better? I really want to get the icon name standardizing done this
> > cycle.
> 
> I won't be at the gnome summit. Neither will the kde people, or the
> other desktops that need to agree on this.

Oh well. Enough artists/etc... will that I think we can get something
started.

-- dobey