Re: [Utopia] gnome-vfs patch, take one

[Alexander Larsson <alexl redhat com>]

On Mon, 2004-05-17 at 23:45, David Zeuthen wrote:
> On Mon, 2004-05-17 at 11:36 +0200, Alexander Larsson wrote:
> > On Fri, 2004-05-14 at 17:09, David Zeuthen wrote:
> > > It would be a change, yes. I'm happy to change it though, but I'm not
> > > sure how to do it in a good way.
> > 
> > I'd like that. There are a couple of reasons I like about having icons
> > for devices for removable media:
> > * We need it for some types of media. The trivial and most common
> > example is the floppy, but there is probably more. If we do it for
> > floppys its nice if we do the same for e.g. cdroms.
> 
> Floppies indeed seem to be the only problem if you look at how e.g. Mac
> OS X handles removable media (not showing drives). Mac OS X has the same
> hard semantics on mounting removable media like other UNIX-like systems
> so GNOME should be able to treat media the same way.

Its the only obvious problem. However, people have been hating and
disabling auto-mounting for as long as we've been shipping it. There are
probable other problems too. Here are some:

* CDROM change detection typically fails on a fair amount of hardware,
see all the bugs for magicdev. This requires lots of blacklisting, and
some way to handle mounting for the blacklisted drives.
* Putting in a CDRW that you want to burn something new on will mount
it, and block burning or erasing.
* Putting in a audio CD with a filesystem on will mount the filesystem
and might block playing the audio.
* I bet other random hardware will have similar issues to floppies
(because that sort of hardware will still work in windows). Things like
jaz/zip drives and similar. Apple control all their hardware, so they
can avoid this, but we do not. For instance, do usb flash card readers
give a signal when you plug a flash card in them?

> Now suppose floppies is really the only problem and there existed a
> gnome-vfs module using mtools, would you consider including that module
> in gnome-vfs. Would OS vendors ship it? 
> 
> (disclaimer: I'm not sure how that would work, so please advise if it's
> been tried before etc. etc.).

KDE uses something like this, so I think it could work. We could ask
them if they've had any issues with it. It needs some integration in
gnome-vfs so that the floppy uris automatically ends up as volumes, but
that should be possible (and that sort of thing was planned anyway).

How would it look though? A constantly availible floppy icon per floppy
drive?

> > * It gives a location in the user interface where you can discover the
> > media-related hardware. And its stable, so when you mount it the volume
> > icon is in the same place as the cdrom was.
> > * We are exposing "unmount" to users, since they have to remember to
> > unmount e.g. a usb media before yanking it. This automatically gives you
> > the state "media in device, but not mounted", which makes it sensible to
> > expose the dual operation (mount) to be "complete". And mount requires a
> > device representation before the volume is mounted.
> > 
> 
> First of all I think it would be visual clutter to expose drives without
> media in the user interface. After all the user does know what drives
> are available since he is sitting right there in front of his computer
> or printer or where ever the drives are physically placed. 

Not horribly so. Its only in computer, which you look at exactly when
you want to interact with drives/volumes. Only mounted volumes show up
on the desktop.

> Further, for discovering devices handling removable storage I think
> something like hal-device-manager [1] (but written properly etc.) would
> suffice. In fact, I've seen many users on Windows get scared of all the
> grey icons with very odd letters like C:, D: etc. Especially Windows
> screw you here with multi-card readers; the user has to manually try
> four drive letters to find his media. In GNOME, it's not unlikely that
> the name of icons for the drives in computer:// would be plain odd like
> 6in1-MMC/SD.
> 
> Second, if you assume the floppy issue is solved, I simply see no need
> for not automounting volumes. Going to the extreme I submit it's a bug
> in gnome-volume-manager that the user can turn off automounting.

Maybe in an ideal world. In practice however i think we'll uncover lots
of small problems with automounting.

> Third, I think I would find it rather confusing that an icon changes
> from a drive icon to e.g. a compact flash icon and back. Icons in
> computer:// should really try to represent spatial stuff users relate to
> like a piece of compact flash media, an icon of a camera, a music
> player, a DVD disc and maybe even a file server. Users don't relate as
> strongly to the drive, that's just boring necessary glue that enables
> them to use their media.

I strongly interact with my usb flash card reader, although perhaps not
as much with the built-in media readers in the computer.

> > > I also thought about a multi-level approach: 
> > > 
> > >  - 6in1 card reader
> > >   - compact flash
> > >   - smart media
> > >   - sd-mmc
> > >   - memory stick
> > > 
> > > with volumes popping in and out at the third level as appropriate.
> > 
> > I dunno. It'll complicate the UI and the APIs require changes. I think
> > this is a bit overengineered in practice, since normal people don't have
> > several 6in1 card readers and other stuff, so it won't be that crowded
> > anyway.
> > 
> 
> I completely agree here, lots of unneeded information in that scheme.
> 
> One reason in favor of including icons for drives with media that you
> haven't mentioned is to maintain the same look and feel as present
> today. Even though I may not agree with that (but I do understand why it
> has to be like this, mostly portability since only fstab and mtab can be
> assumed), I can see the benefits in not changing it. 
> 
> Anyway, I won't have time to finish the patch before next week anyway
> because I'll be away from computers wed-sun, so please let me know if I
> should put drives in or not  - I don't feel too strongly on the issue.

The last time this argument was going on I ended up on the pragmatic
side, going with devices visible in the UI. I feel that there are good
arguments on both sides, however we once made a decision, and its now
implemented and even exposed in the APIs. So, I would prefer if we kept
the current way instead of changing again. At least thats my current
opinion, although I don't violently disagree with your position either.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a short-sighted chivalrous inventor on the edge. She's a beautiful 
belly-dancing stripper from aristocratic European stock. They fight crime!