Re: Volume handling proposal

[Gregory Merchan <merchan phys lsu edu>]

On Tue, Sep 16, 2003 at 03:40:20PM +0200, Alexander Larsson wrote:
<snip>
> The Players
> -----------
<snip>
> Issues
> ------
<snip>
> Usage
> -----
<snip>

All looks fine to me. One thing caught my eye though:

> ... some ... use [the desktop] mostly to launch stuff.

This use should become rare as GNOME improves and moves away from an
application-centered interface.


> Proposed Model
> --------------
<snip>
> The desktop will also show icons for [stuff that's not always there, and
> not always the same as the last time it was there]

Fair summary?  Maybe they should be called "transient devices".

I'd had the idea of using the notification area to indicate such devices
had become available. It's easier to get to and usually more visible than
the desktop is. It's in keeping with the purpose of the notification area
so long as the icon only appears when the device is available and disappears
when it isn't. All the behavior should remain the same as if the desktop
icons were used. Device icons might even afford being dragged to the desktop,
and back, as the user desires. Whether the notification area is running and
whether a particular icon is displayed are programmatically accessible, so
Nautilus could take appropriate action in either case.

<snip>
> Note that this does not include the root, nor "Computer". I think
> these are not used often enough to require a desktop icon.

Where is "Computer" if not on the desktop? As we move to a spatial Nautilus,
we should have a space for it. The menus serve as shortcuts, but aren't "the
real thing".

I'm not being inconsistent by saying "Computer" needs a place and some
devices should show icons in the notification area (NA). The NA devices
would still have a place in "Computer" and the NA would serve as both
indicator and shortcut.

<snip>
> Note: the described behaviour is the default. Some of this will be
> made configurable, but hopefully not that many prefs will be needed.

I think DnD is the way to allow configuration without adding prefs; as I
mentioned above about device icons on the desktop or in the notification
area.

> Implementation
> --------------
<snip>

> Open Issues
> -----------
>
> How do we handle burn:? I really like the way where its sort of
> invisible in the UI until you insert a blank cd and magicdev detects
> it. This doesn't work without magicdev, but maybe clicking on the CD
> in computer could try to detect a blank cd and go to burn:. Of course,
> this gives problems with rewriting CD-RWs and burning .iso images, so
> i guess this has to be visible some other way in the UI too. Maybe
> right click on the cd device icon and select "burn to cd"?

I would treat the CD-RW as two devices - one real, and one virtual. Both
would have a fixed place in "Computer". The real device would act like
read-only media. The virtual device - call it the "CD Queue", "CD Spool",
or something like that - would act like a printing spool does, except it
wouldn't start automatically. With sanity checking by the computer, the
user could start a burn from something in the spool view, or by dragging
the spool's icon to the real device's icon, or by menus.

When a CD-RW is mounted, the shortcut icon (on the desktop or in the
notifcation area) should be the real device if the CD contains data, or
the virtual device if it is blank.

Having the real CD icon and folder silently refuse drops would be a pain
in the ass and an impediment to new users. Worst-case, it should accept
the drop and alert the user that drop went to the virtual device. But,
alerts suck. There has to be a better way to handle this. How do we make
sure users don't remove the CD-RW thinking it's ready?

Maybe the real device view should use some special icon to indicate things
in the queue? The special icon would perhaps be similar to the special icons
for mountable-yet-unmounted devices.

This is very similar to a printer and it's spool. The important differences
are that the printer is write-only and "forgiving" - bad prints waste a bit
of paper which is cheap, bad burns waste an entire CD which is expensive.
Remembering those differences, I think existing treatment of printing
provides knowledge users can transfer to burning. I'm just not sure how to
accentuate the differences.


> Still not sure what roots make sense in the file selector. Do we want
> to allow mounting of e.g. floppies from the file selector?

Dunno 'bout that either. File selectors dialogs are stupid. :-)


> What about printers etc? "Computer" is essentially only "filesystems
> accessible on the computer" right now, but it *could* be extended to
> be more like a "hardware connected to the computer", although that
> makes network filesystems not fit in there as good, and introducing
> non-files in the filesystem is dangerous as noted above.
<paste>
> Its might make sense to present some other hardware elements in the
> same way as volumes, even though these are not really
> filesystems. Things like printers and scanners. This can be useful,
> since these highly-visible external hardware elements otherwise have
> no corresponding in-desktop element. However, it is also a bit
> dangerous, since these items will look like files but really will be
> something completely different, therefore they might break the users
> conceptual model (what happens if you copy one to a remote share? Can
> you rename them? What happens if you drop one in the trash? What are
> their size? What happens if an application decides to load such a
> "file"?).

I think it make sense. Copying, and probably moving, would have to be denied.
Instead shortcuts/links would be created in response to user action.

Renaming depends on the particular device.

The trash would refuse drops, much like a real trash can refuses to contain
anything that doesn't fit through its orifice. :-)

Size? I don't understand.

The simple solution for erroneous application loading is: don't let
applications load anything. Leave it to the file manager to open documents
appropriately. :-)  Something indication of device nature from VFS is
probably the expedient solution until we're rid of file selector dialogs.


Cheers,
Greg