Icon-mime type associations

[Rob Lanphier]

Hi Ryan,

I agree that option #3 below makes the most sense.  It doesn't appear as
though you have a strong preference recommendation between suboption A
or B below.

My recommendation would be a variant of option A below, which would be a
bit of a compromise between your proposal and the status quo.  For MIME
type "audio/foo" handled by "fooplay", treat
/usr/share/icons/hicolor/48x48/mimetypes/mime-audio:foo.png as a cache
for the icon associated with "audio/foo".  The normative copy of this
icon, assuming "fooplay" is the default app to play this type, should be
installed at
/usr/share/icons/hicolor/48x48/mimetypes/fooplay-mime-audio:foo.png

To follow this proposal, the fooplay installer MUST install the app icon
at fooplay-mime-audio:foo.png.  The installer SHOULD NOT install an icon
at mime-audio:foo.png unless that app is the default for "audio/foo",
but an app SHOULD "populate the cache" if there is no icon there or if
the icon is inconsistent with the user prefs.

There are plenty of opportunities to ensure that
fooplay-mime-audio:foo.png is synchronized with mime-audio:foo.png that
I would imagine are minor in their implications on performance.  Below
are suggestions of some places:

*  The MIME-type configuration tool can ensure that
fooplay-mime-audio:foo.png gets copied over to mime-audio:foo.png when
that MIME-type is visited/configured
*  Right clicking/double clicking on the file or other operation where
the association already needs to be referenced.
*  The fooplay application itself can check up on this association.
*  Startup
*  Background task

I would imagine that if the installers and the MIME-type configuration
tool do their job, the other sync mechanisms would be unnecessary.  A
clear specification of the policy and rigorous enforcement by
distributors should almost completely obviate the need for extra sync
code.

Rob

On Mon, 20 Sep 2004 14:48:23 -0700, Ryan Gammon <rgammon at real.com> wrote:
> Hi all,
> 
> I thought I'd try to summarize here the discussion that's taken place so
> far:
> 
> The problem:
> RealPlayer wants to install fallback icons for datatypes that the
> desktop may not have covered in its icon theme. The specs roughly say
> that these icons should go in /usr/share/icons/hicolor/48x48/mimetypes.
> 
> The specs also (roughly) fixes the name of the icon for the new
> datatype. audio/foo -> mime-audio:foo.png for example.
> 
> If two apps want to install a fallback icon for a given mime type, they
> will conflict.
> 
> There's some debate as to whether or not this is a problem.
> 
> I feel the desktop icon theme should get first crack at the document
> icons -- what we're talking about here are the hicolor fallback icons only.
> 
> The solutions:
> 1. Apps don't install icons for new mime types. If a user goes to
> Nautilus, they'll see their .foo files with a generic icon. In the case
> of audio/* and video/*, one could create a fallback type of
> mime-audio.png, but this doesn't solve the general problem --
> application/smil for an example that's relevant to us.
> 
> 2. Apps fight for the hicolor icon. Whoever gets to the /usr/share/icons
> hicolor directory first/last gets the icon.
> 
> 3. mime type fallback icons are per-app. The default app for a datatype
> gets to define the fallback icon.
> 
> I think (3) is best for the user. The app supporting the datatype has
> the best chance of being able to display something meaningful to the
> user about what that document type is. With (1), we'd display either
> nothing, or something very generic. With 2, behavior would be random.
> There's potential for an app to be default for the type, but for the
> icon to come from a different app. This is confusing. The potential
> conflicts here also complicates packaging.
> 
> The implementations:
> 
> There are a couple of ways 3 could be implemented. I've listed a few here:
> 
> A. Apps install their document icons to
> /usr/share/icons/hicolor/48x48/mimetypes/<app name>, where app name is
> something like hxplay. Alternatively, apps prefix their icons in
> /usr/share/icons/hicolor/48x48/mimetypes with hxplay, so the hxplay
> fallback icon would be hxplay-mime-audio:foo.png
> 
> Either apps like nautilus can look for these alternative fallback icons
> when trying to associate an icon with a datatype, or another app can
> update mime-audio:foo.png to point to hxplay-mime-audio:foo.png when
> hxplay is the default app for a given datatype.
> 
> This is based on a suggestion from Thomas Leonard.
> 
> B. Icon/app associations can be declared in the .desktop file, where the
> mime types supported by the app are declared ... my original suggestion.
> 
> C. Add support to the .xml files in /usr/share/mime/packages for setting
> the "fallback" icon name, similar to the way .keys files worked.
> 
> One of the criticisms of per-app document icons is that it would consume
> excessive memory and cpu time.
> 
> With (A), we are either
> i. introducing a fixed overhead of setting symlinks in mimetypes
> whenever the default app for a datatype changes or
> ii. introducing the overhead of an icon lookup when a datatype is
> unknown. If nautilus needs an icon for audio/foo, it has to do a default
> app lookup for audio/foo, and then an icon lookup based on that app
> name. This is an additional default app name lookup. I believe this
> information comes from a hash table lookup in gnome-vfs.
> 
> With (B), we're in a similar situation as (A) -- an extra lookup of the
> default app & .desktop info for audio/foo, from which we could extract
> an icon name.
> 
> With (C), it's unclear how the app-specified icon would get
> propagated... maybe this would be a update-mime-database, which would
> mean that update-mime-database would get run everytime a default app
> changes. Awkward.
> 
> I'm sure there're plenty of other options I've missed here -- feel free
> to add to the list.
> 
> 
> 
> --
> Ryan Gammon
> rgammon at real.com
> Developer for Helix Player
> https://player.helixcommunity.org
> 
> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg
>