Re: [Usability] File operations dialog redesign

[Shaun McCance <shaunm gnome org>]

On Mon, 2008-06-09 at 00:59 +0100, Matthew Paul Thomas wrote:
> Matthew Paul Thomas wrote on 01/05/08 22:34:
> >...
> > It would be easy to let this drift into something complicated that 
> > looked like a download manager, which would be ugly and cramped in the 
> > usual case of presenting just one move or copy at a time.
> >...
> 
> With that in mind, I've revised
> <http://live.gnome.org/Nautilus/ProgressWindow> taking into account all
> your feedback.

Just one nitpick from me.  You say on that page:

  The button to the right of (and vertically centered with)
  the progress bar should read “Cancel” if the task is still
  in its pre-flighting stage, or “Stop” if the task has begun
  making changes on disk.

I know we haven't addressed Cancel/Stop yet for the terminology
guidelines (and I know I haven't been doing them much lately),
but the difference between Cancel and Stop (as I'll propose it
anyway) is that Cancel denotes something that can be backed out
of completely.

With moving or copying a single file, the data is copied into
the new file without the original being affected at all.  If
you're moving the file, the original should be unlinked only
after the new file is completely written.  If you cancel the
operation, the new file can (and, I think, should) be deleted,
leaving the original still in place.

Now, with a multiple-file move or copy, this isn't the case.
Files are copied one-by-one.  So even if no particular file
is left in both places, you're left in a sort of weird state
of files in both places.  So that needs to be Stop.

--
Shaun