mime-type icons, a proposal

[Alexander Larsson]

On Tue, 2004-09-28 at 14:35 -0400, Rodney Dawes wrote:
> 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.

One of the major reasons for writing the icon themes specification was
so that the "icon" field in the desktop file specification could be
finalized and standardized, so that kde apps in the gnome menu (and vice
versa) wouldn't look like total ass. Are you now proposing that we don't
use the icon theme spec for this?

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

All apps are meant to install icons in hicolor. And kde apps are
supposed to be doing this already:
http://developer.kde.org/~larrosa/iconthemes.html

The reason for the naming is historic, but that matters little. What
matters is that its a way to actually share icons between desktops, in
this non-perfect world we have where this is needed.

I can agree that the whole icon theming system is a bit bizzare, and its
probably not the way I would have designed it if there was no prior art
that we need to be compatible with. However, in whatever form you design
it, icon theming will need a way for apps to install fallback files for
special icons they use that are not yet in all themes. And the
application used for launching the app is a typical example of such an
icon.

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

If we ignore implementation details in designing the spec such that they
result in any application using the spec getting major startup
slowdowns, then we have failed. I will at least not implement that
spec. 

The rule I had was a generic one and not in any way related to "API". 
Basically it codified that we should not keep making the same damn
mistake that the icon theme spec did that is causing Gnome app startup
times to be so bad.

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

The context attribute can only be used to get a list of the icons in a
particular context, its not used for lookup. Its used in kde to allow
the icon picker dialog to have an easy way to browse between various
types of icons.

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

Well. For all application/* types we'd list their generic icon in the
freedesktop.xml file, and we can make that one override any app-specific
mime info. For the audio/* and video/* ones we'd likely leave that out
of the file and just use the "current method". In these cases i guess an
app-added xml file could change the generic icon of a type as a way to
get their own icon in. I guess we could list the generic types in
freedesktop.xml for all types, or we could assume 3rd party apps will
play nicely with the system.

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

Thats the only way to do it, yes. We have to really get consensus on it
though, the actual people who will be doing the changes in gtk/kde/gnome
etc will have to agree. And things like backwards compatibility has to
be taken into consideration.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a leather-clad guerilla cyborg from the 'hood. She's a cynical 
French-Canadian politician living on borrowed time. They fight crime!