Re: [Usability]Dealing with files in Gnome
- From: textshell neutronstar dyndns org
- To: desktop-devel-list gnome org
- Subject: Re: [Usability]Dealing with files in Gnome
- Date: Tue, 1 Apr 2003 19:40:48 +0200
On Tue, Apr 01, 2003 at 12:20:54PM -0500, Sean Middleditch wrote:
> On Tue, 2003-04-01 at 11:52, textshell neutronstar dyndns org wrote:
>
> > Please keep in mind that adding names to a list might not be enough. On of the
> > biggest problems of the cut and paste stuff in the file-manager is that copy
> > doesn't copy the file. So the user *thinks* he can delete it and later use
> > paste. I think this general problem applies to Pick and Drop as well. I think
> > protection against deleting a picked file is important. Maybe Nautilus could
> > hold an file descriptor open for all picked files (Inux would ensure that the
> > files won't go away, either by umounting or deleteing). I think this protection
> > is more important to get the feature user ready than the wording (I think the
> > pick and drop stuff has advantages).
>
> Potential problem here is when I want to copy a file from one floppy to
> another - merely holding the file descriptor open won't help any.
Hmm, good point. I didn't think about that. We could try to detect any media
that seems no-fixed and just copy the file right away to a temp locatiion.
But that seems to be a typical point of tries to be smart. We most likely would
get this in enough cases wrong. (Coping to much, to the wrong temp location etc)
>
> This is similar to the "Move to Trash" problem with varied file
> systems. It would be nice there if the Move to Trash didn't appear if
> moving to trash isn't possible (confusing), or if it just copied to
> trash if rename()ing isn't possible.
Yes, that's right, maybe this could even work.
>
> Moving files about in general on Nautilus doesn't hide enough of the
> UNIX limitations/architecture. :(
>
Well we *could* just hide it away and take the consequences. Alway copy the
files (Mostly fits the Copy/Cut/paste model; moving the file to a temp location
on Cut...) and just take the performance penality and get rid of the UNIX
reasons for the behaviour (BTW this problem exists in win XX, too).
That would be force the usual office application behaviour on nautilus. And then
(maybe) add a one step copy/move somewhere to the UI for the boundary cases that
are impossibe/not acceptable with the copy/past model)
Martin H.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]