Re: [Utopia] gnome-vfs HAL patch, take 3

[David Zeuthen <david fubar dk>]

On Fri, Jul 09, 2004 at 11:26:53AM +0200, Alexander Larsson wrote:
> On Thu, 2004-07-08 at 23:45, David Zeuthen wrote:
> > Hi,
> > 
> > Attached are the latest patches against GNOME VFS to use HAL for
> > discovery of physical storage devices. There is one against HEAD and one
> > against the stable 2.6 branch. It requires a working installation with
> > HAL from CVS and the update-fstab.sh callout enabled; gnome-volume-
> > manager is optional. For this patch you also need a recent version of
> > GNOME VFS that doesn't crash when a name contains a '/' character.
> > 
> > By default the patch doesn't change anything; you will need to pass --
> > enable-hal to configure to use it.
> 
> All right. I commited this to HEAD. Although i had to remove the #ifdef
> USE_HAL around dont_use_hald to make it build without hal.
> 

Much thanks.

> I don't have hal installed on my system, so i can't test this, but I
> assume you guys tested it. The non-hal parts looks ok to me, and I
> mostly glanced at the hal-specific parts which looked alright. 
> 
> One thing struck me though. In _hal_add_volume it seems like we're
> always creating a drive for each volume. Thats not necessary in general.
> Its perfectly fine for a volume to not have a drive. In fact, thats
> expected behaviour for volumes that are not "removable media plugged
> into a drive".
> 

Ok, this makes sense, I didn't catch that one. For some drives
(especially external harddisk enclosures connected by USB) we can't
really realiably determine whether the drive contains removable media,
so in that case we'll add the drive anyway. But I'll make the change.

> > 
> >         Find a way to expose the HAL UDI of a drive and a volume such
> > that e.g. Nautilus can extract more properties on the device
> 
> What about the attached (untested) gnome-vfs-export-hal-udi.patch? It
> exports the hal udi as a string, whenever its availible. This lets
> nautilus recover UDI information from computer:// since the Drive/Volume
> id is availible in the desktop files there. This would make it easy to
> do things like adding emblems in nautilus.
> 

This looks good, I'll try it out tonight.

> >         When libgphoto2 is completely halificated, get the GNOME VFS
> > backend to work and add functionality (in this file) to show a camera
> > icon that links to the appropriate GNOME VFS URI. (when the camera is
> > not usb-storage based of course)
> > 
> >         Do the same for MP3 players when GNOME VFS backends for these
> > emerge.
> 
> Are we totally sure we want to do this? Are these devices really generic
> filesystems exposable in gnome-vfs? Can you save your word document on
> the camera? Does it make sense?
> 

Regarding whether this is technically possible, I'm quite sure it is;
libgphoto2 exposes generic filesystem operations that should map directly
to GNOME VFS; there is even some documentation mentioning a kernel module
for libgphoto that speaks to a userspace daemon for exposing a kernel
level filesystem which leads me to believe that the semantics of the
file system operations even maps to POSIX.

Would a camera be upset if I had cv.doc in the root folder? I dunno,
but according to 4.1 of http://www.exif.org/dcf.PDF this seems legit.
And it works with my Canon, FWIW. Either way, we can blacklist certain
cameras if need be.

> I think its better to detect devices when plugged in, and perhaps launch
> the right app, or maybe just show the device as plugged in somewhere
> (notification area?). And then the application that handles cameras
> should of course use hal and automatically do the right thing wrt its
> user interface when the camera is plugged in. 
> 

That's right, we probably want to do that anyway, launching applications
etc. should be in gnome-volume-manager.

>From what I can see many people like to use "life style" devices for
data storage, and for cameras it is really a storage device, although
the "card reader" happens to be a camera possibly with a proprietary
protocol to access it through e.g. libgphoto2.

But I agree this clutters the computer:/// location, I mean continuing
my line of argument more or less any device with storage capabilities
will end up in computer:///. 

Heh, look at this

 http://www.memoryxflash.com/fpmcus.html

Should we show a mouse icon here? I don't think so, we should show the
Compact Flash icon because it's a Compact Flash card reader. What
about a PDA with a CF card slot? Here we should show a PDA icon since
the device is a PDA and the files will be relevant for the PDA?

Maybe computer:/// should exactly be the location to look for your
devices that has storage no matter what method we use to connect to
it? And the icon used should reflect what the device is.

I dunno... (and that's why I'm rambling above :-)

> >         Please look at GNOME Bug 143888. Fixing this will allow a
> > reasonable good desktop experience without automounting or autodetection
> > of media.
> 
> I think John Palmeri is working on this.
> 

That's great, I'll add some more comments later.

> >         When the patch is used GNOME VFS doesn't look for anything in
> > /etc/fstab or /etc/mtab; this means that e.g. SMB or NFS network mounts
> > are not shown in computer:///. Should this be changed?
> 
> I dunno really.
> 

Ok, me neither, this can always be revisited.

> > ICONS
> > 
> > This patch by default uses a new set of icons as discussed in this
> > thread on utopia-list
> > 
> >  http://mail.gnome.org/archives/utopia-list/2004-July/msg00009.html
> 
> Just make sure you get jimmac to draw the icons for you and put them in
> gnome-icon-theme.
> 

Great, will do.

Cheers,
David