Re: Nautilus usability and nit-picks
- From: "Shahms E. King" <shahms shahms com>
- To: Nautilus List <nautilus-list gnome org>
- Subject: Re: Nautilus usability and nit-picks
- Date: 23 Aug 2002 13:00:43 -0700
*snip*
>
> > Completely agreed.
> >
> > Perhaps Move should be the default, and copy available in context as
> > optional. Obvious exceptions are detachable devices like Cd-Roms,
> > floppies, etc ...
>
> I agree too. Maybe the distinction should be between "local disk" and
> "remote and removable filesystems" (NFS, SMB, ftp, DAV etc) - copy to
> those, move to local disk by default? The only problem with moving
> indeed is that if you move to a remote disk you might want to keep a
> copy, so perhaps default to "copy" for that reason on remote
> filesystems.
That is, I believe, how it currently is. But this behavior becomes
unexpected and counter-intuitive in the case of, say, NFS, because this
is mounted as a part of the local filesystem and the fact that it isn't
really local should not be visible to the user. However, if you were to
access that same export via, say, nfs://server/path THEN copy rather
than move would make sense.
Working within the 'local' directory structure should maintain a
consistent behavior, regardless of the underlying implementation of that
particular directory/mount. The same thing applies to smb:// versus
smbfs, http:// versus davfs (yeah, it exists), etc. There is a lot of
work being done in gnome-vfs (and I'm guessing Nautilus) for is_local
to work and return FALSE on NFS mounted files, when a large part of
that, IMNSHO, is counter-productive and incorrect. I read a discussion
of something similar on the gnome-vfs list a while ago, I believe.
is_local should return TRUE for anything in the file:/// heirarchy and
the API should probably be extended to cover the 'other' semantic
meaning of is_local (is_fast or some such).
--Shahms
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]