gvfs hal volume monitoring backend



Hi again,

Here we go with the patches for the hal volume monitoring backend:

 http://people.freedesktop.org/~david/gio.patch
 http://people.freedesktop.org/~david/nautilus.patch
 http://people.freedesktop.org/~david/gvfs.patch

First there's a gio patch with some feature additions and fixes for the
volume monitor. One fix is to make it handle when the constructor for a
GNativeVolumeMonitor fails - this is important to handle as the hal
volume monitor will fail if hald isn't running. I'm not happy about how
I've implemented it; suggestions welcome. Another fix is to properly
unref the child monitors when finalizing. 

I've also added locking in _g_get_mount_for_mount_path() so native
volume monitors don't have to worry about that. It's not clear to me
whether _g_get_mount_for_mount_path() is allowed to block; I *think* it
is but docs are scarce on this point. There's also a TODO item in that
function with some more unanswered questions.

Also, the gio patch should bring the GUnixVolumeMonitor to a state where
it's feature complete; eject now works.

Second, there's a patch for nautilus to take advantage of the new API
(mostly that eject() is now on GMount, GVolume and GDrive).

Finally, there's a patch against gvfs with updates for the API changes
and then the hal backend itself. At the moment it's using dbus-glib-1 in
addition to libhal; not clear to me why it shouldn't. Thoughts?

Also, there's a ton of new icon names used [1]; here's example icons to
test that I've used

 http://people.freedesktop.org/~david/gvfs-hal-icons.tar.gz

which is basically just Tango icons with ugly labels on top. There are
necessary as we don't yet have fallback code integrated. Just untar this
in ~/.icons and it should work. I need to get this into the icon naming
spec too. 

One icky thing is that we use the same icon for representing a drive and
representing unmounted media in that drive. One idea is to append the
suffix "-hasmedia" to the drive icon name, e.g.

 drive-removable-media-usb -> drive-removable-media-usb-hasmedia

and icon fallbacks would save us. However, I'm not sure it's worth it.
Most people will probably only see the icons for mounted media due to
automounting and polling of drives and the fact they probably don't use
computer:///. Thoughts?

I've not yet hooked up the volume:// stuff; wanted to get this in first.
Thanks for reviewing it.

      David

[1] : See [2] for the actual icons. Keep in mind that thanks to icon
fallbacks the stock GNOME desktop need not to ship all of these; e.g.
the stock icon theme would only ship drive-harddisk and not all
of drive-harddisk-ata, drive-harddisk-usb and so forth. Depends on
what you want etc. etc.

[2] :

$ ls ~/.icons
drive-harddisk-ata.svg              media-optical-audio.svg
drive-harddisk-ieee1394.svg         media-optical-bd-re.svg
drive-harddisk-scsi.svg             media-optical-bd-rom.svg
drive-harddisk-usb.svg              media-optical-bd-r.svg
drive-optical-recorder.svg          media-optical-cd-rom.svg
drive-removable-media-ata.svg       media-optical-cd-r.svg
drive-removable-media-flash-cf.svg  media-optical-cd-rw.svg
drive-removable-media-flash-ms.svg  media-optical-dvd-dl-r-plus.svg
drive-removable-media-flash-sd.svg  media-optical-dvd-ram.svg
drive-removable-media-flash-sm.svg  media-optical-dvd-rom.svg
drive-removable-media-floppy.svg    media-optical-dvd-r-plus.svg
drive-removable-media-ieee1394.svg  media-optical-dvd-r.svg
drive-removable-media-scsi.svg      media-optical-dvd-rw-plus.svg
drive-removable-media-tape.svg      media-optical-dvd-rw.svg
drive-removable-media-usb.svg       media-optical-hddvd-rom.svg
media-flash-cf.svg                  media-optical-hddvd-r.svg
media-flash-ms.svg                  media-optical-hddvd-rw.svg
media-memory-sd.svg                 media-optical-mo.svg
media-memory-sm.svg




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]