storage.icon.* vs info.desktop.icon

[Karl Relton]

Hey diddle diddle - no reply from anyone on this?


Dear friends

Bug http://bugzilla.gnome.org/show_bug.cgi?id=545025 picks up on the
fact that for specifying icons for storage devices, the HAL spec
specifies storage.icon.drive and storage.icon.volume as the properties
(on the object with info.category=storage) to use, whilst gvfs uses
info.desktop.icon (on the drive and volume objects respectively).

The patch attached to the bugzilla entry attempts to force gvfs to
honour the spec - although the patch is not quite right and problematic
in the following repsects:

- It looks up storage.icon.volume from the volume object, when this
property will actually be on the drive object. The patch can obviously
easily be correct in this regard.

- In the same code, info.desktop.name is used to supply a custom name
for the drive/volume. The HAL spec has no equivalent for this, so I
haven't patched that.

- Elsewhere, i.e. daemon/gvfsbackendgphoto2.c,
monitor/gphoto2/ggphoto2volume.c, info.desktop.icon (and name) are used
on gphoto controlled objects. Its not clear to me that these would ever
get the info.capability=storage property, so I haven't patched these.
But of course that means we have storage.icon.drive in one place, and
info.desktop.name in another.


Perhaps the spec is just out of date, and current gvfs code reflects
today's intent?

I can see that just using info.desktop.icon (and name) is potentially
cleaner, since
- it can be used on more than just storage objects
- it potentially allows for a drive with multiple volumes to have a
different icon/name assigned to each volume.

If the spec is updated, with storage.icon.drive/volume deprecated, then
we can forget my patch and void the bug (and I'll update the .fdi on my
computers!).

Cheers
Karl