Re: Icon Metadata for Filesystems

[Rodney Dawes <dobey gnome org>]

Hi,


On Thu, 2008-09-04 at 13:35 -0400, David Zeuthen wrote:
> I really like the idea that both icons and the accompanying name can be
> specified in a file in the root of a volume. I envision that both linux
> enthusiasts, other desktops as well as hardware vendors (down the road,
> anyway) will be able to take advantage of this. To enable widespread
> usage, I think this needs to be specified in a standard somewhere.

I think you're jumping the gun a bit here with excitement. I'm not sure
this necessarily makes sense for things we already have a solution for,
like optical media. We want to match other operating systems' behavior
when dealing with media that would appear under them as well. That means
having a limit of 11 characters on FAT partition volume labels, and
using autorun.inf to specify a local icon on the storage media. My patch
is much better suited to local mounts that HAL wouldn't deal with in
the first place. Think user-local fuse mounts and the like. If a web
service wanted to provide a mountable virtual drive, this would be a
way for them to specify a meaningful volume name, and icon, for that
service when it gets mounted.

> Also, as briefly mentioned on IRC, I think this may be applicable to
> more than just volume icon and names. For example, digital audio players
> come to mind. Right now, the way we enable digital audio players is
> through quirks in HAL. This is suboptimal because it relies on the users
> OS being up to date with fdi files. It would be much better if a file
> was present on the device indicating that it's a digital audio player as
> well as what input/output are supported.

We need some way to install fdi files on user systems, and not a method
to work around any flaws in the current system there. If having a
capabilities property in HAL is suboptimal, then we should probably look
at exposing those capabilities in some other way through HAL. Parsing a
file on the device to determine what it can do isn't really any better
than parsing an fdi file on the computer to do the same. We need some
service like foomatic, or the driver search in Windows, for when a user
plugs in a new device, to download/install the appropriate fdi files,
any drivers if necessary, and icons for the device. We shouldn't require
users to specify what their hardware can do, so they can use it.

> It's also worth pointing out that the the shared mime info spec recently
> gained support for content types for volumes (e.g. x-content/*), see
> 
>  http://lists.freedesktop.org/archives/xdg/2008-June/009674.html
>  http://webcvs.freedesktop.org/mime/shared-mime-info/freedesktop.org.xml.in?r1=1.369&r2=1.370
>  http://webcvs.freedesktop.org/mime/shared-mime-info/freedesktop.org.xml.in?r1=1.371&r2=1.372
>  http://webcvs.freedesktop.org/mime/shared-mime-info/shared-mime-info-spec.xml?r1=1.60&r2=1.61
>  (I'd link to the actual spec in HTML form but it's not updated on the
>   fd.o servers... grrr)
> 
> For example there's this
> 
>   <mime-type type="x-content/audio-player">
>     <!-- see fd.o hal spec -->
>     <_comment>portable audio player</_comment>
>   </mime-type>
> 
> and gio 2.18 recently gained
> 
>  g_mount_guess_content_type ()
>  http://library.gnome.org/devel/gio/unstable/GMount.html#g-mount-guess-content-type
> 
> and the thinking is that applications like Rhythmbox (or whatever)
> should use this API to find e.g. digital audio players. One thing we
> still need is the ability to specify additional meta data. Such as what
> input (for e.g. recording) and output (for e.g. playback) formats are
> available. And where the default music folder is; basically a subset of
> 
>  http://people.freedesktop.org/~david/hal-spec/hal-spec.html#device-properties-portable_audio_player
> 
> My thinking is that this information will be available _somehow_ through
> gio. Need to think more about that.
> 
> So my proposal would be a spec that
> 
>  - Introduces a new .xdg-volume-info file
>    - format: .desktop-ish / ini file, UTF-8
>    - location: root of the volume
> 
>  - defines the contents of .xdg-volume-info
> 
>  - The icon section could look like this
> 
>      [icon]
>      xdg-icon-name=multimedia-player-acme-frobnicator   # references the icon naming spec
>      icon-file=.my-file.svg                             # for shipping an icon with the device,
>                                                         # path is relative to the root
> 
>    stating that implementations using this file must prefer icons
>    resolved from $xdg-icon-name over $icon-file.
> 
>  - We'd then have a [name] section, an [x-content/audio-player] section
>    and so forth.
> 
> Or something. The format of the file needs more thought, this is just
> what I came up with in 10 minutes. I'd be happy to work with you on such
> a specification, including bringing it through the xdg-list process.

I think perhaps just having the following for .xdg-volume-info is best:

[Volume Info]
Name=iDisk
Icon=drive-harddisk-remote-idisk

And we could just have Icon allow relative path filenames as well, so
that you could specify Icon=.foo.png if one wished. If you want more
complex data like capabilities and such for HAL, perhaps you could just
allow reading a .hal-info.fdi file on the volume, so that one could just
stick an appropriate fdi file on the device and have it just work. That
would probably be better for hardware vendors to do. We don't need two
methods to specify such information for one hardware abstraction layer.

> Btw, I'm sorry to make your simple proposal (and patch!) a lot more
> complicated but I really think the problem you're trying to solve is a
> specialization of a more generic set of problems that we can easily
> solve at the same time.

> Thoughts?

The problem I'm trying to solve really is more for volumes which HAL
does not deal with at all, such as user-local fuse mounts. For things
that HAL does handle, I think the fdi files can already solve all of
these issues.

-- Rodney