Re: Icon Metadata for Filesystems

[David Zeuthen <david fubar dk>]

Hi,

Sorry for not replying sooner, labor day weekend plus a packed schedule
this week.

On Fri, 2008-08-29 at 12:27 -0400, Rodney Dawes wrote:
> Holas,
> 
> I have written the attached patch to GIO, which implements getting an
> icon name for a mounted volume from an .iconrc file within its file
> system. David Z suggested that it might be useful to also allow other
> information to be provided here, such as the volume name to use in the
> display. I'd like to get some definite agreement on the file name to use
> here (davdiz suggested possibly using .xdg-volume-info), and get the
> patch upstream. I implemented this in GIO, as it appears the HAL is not
> aware of all possible mounts (particularly user owned fuse mounts), and
> this should work for all volumes. Particularly, some fuse mounts may
> want to provide this metadata file virtually, to specify their icon.
> 
> What do you think about the file name, and the patch in general?

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.

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.

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.

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?

     David