seems like a wont fix, but the comments seems useful for documentation.

Does the mac use cut, copy and paste as well?

OK, so:
1) Greg: this is a spectacular confusing and poorly-written bug
report, even by my low standards.
2) I'm not sure that these comments are particularly useful for
anyone, since they aren't structured or constructive.
3) There comes a certain point (as all the usability people will tell
you) when familiarity becomes more important. 10 years ago, this was
probably a very valid suggestion. It just isn't anymore.
4) Consistency with the rest of the system is important and useful, as
well, not just consistency with windows. Everything else uses
cut/copy/paste terminology; Nautilus will too.
So, marking NOTABUG. Sorry to have wasted bits on this.

What should the bug report be? The entire notion of Cut/Copy/Paste
of files is absurd. Filing a bug report on it is like arguing
hermeneutics with Bozo the Clown; but how else do fundamental flaws
get fixed?

There is an existing model for keyboard accessible drag and drop - 
that of Pickup and Drop menu items. In that, one place on the item
popup menu is Pickup, unless something has already been picked up.
When something has been picked up, that item is instead a Drop
submenu containing: Copy, Move, Create link, Cancel drag.

And at what point does familiarity override reason?
Where else are files being cut, copied and pasted?
Where else does a cut not remove the item?
Where else does copying a file not actually make a copy?

Well, you could start by actually mentioning what you're talking about
before the last sentence of your bug. That tends to make things more
clear. stream-of-consciousness does not make for a great discussion.

>And at what point does familiarity override reason?

I'm not an expert; I can't judge. But it probably starts somewhere
before '99% of the computer using world has been using this model for
more than a decade.'

The bug is filed against the Cut/Copy/Paste/Undo component of the
GNOME file manager and I repeatedly speak of that operation on files.
The entire component makes no sense. What I'm talking about I
specified before even the first sentence of the report.

When familiarity is allowed to override reason, the whole species
is damned.

>When familiarity is allowed to override reason, the whole species
>is damned.

When bug reporters resort to ridiculous over-dramatism, their entire
body of bug reports tend to get ignored. Further, ff your reports
refrained from comparing developers to bozo the clown, or declaring
your judgement of reasonability to be infallible, your bug reports
might do better- if you aren't providing code, you'd be best advised
to persuade instead of chastise and mock.

Ridiculous over-dramatism? Human beings survive by reason; if they
relinquish their means of survival, they die.

I did not compare anyone to Bozo the Clown. Read.

I made no claim of infallibility.

Pre-1.0 Nautilus did not have this bug. The developers then objected
to adding the bug. Why they surrendered is a mystery to me.

Wow!

Ok, so here goes.  The only reason that this was added was becuase a
lot of users requested the feature.  If I recall, it was also
requested by Jacob's long rant about Nautilus.

I, for one, having worked on Nautilus think that this "feature" is
appaling and that the whole "cut/copy/paste" idiom doesn't work with a
file.  They're supposed to be used inside of documents on text/images
and the such.

Let's not resort to calling names, but let's let Seth decide this one,
Louie.  With all due respect, you job isn't to decide user interface.

Josh

I don't see a particular reason to remove the feature, and it helps
people get things done in a way that is familiar to them. 

I'd love to see alternatives that solve the same problem (people don't
like dealing with multiple file windows for performing copy/move
operations); perhaps some sort of NeXT shelf mechanism, perhaps there
are other good ideas. 

But even if we get such a mechanism I don't think we should remove
cut/copy/paste of files because so many Windows users already work
within that model and it doesn't really interfere with other
operations. Presumably a better mechanism would be more obvious, so
non-Windows users would learn it the better way.

Greg points out numerous UI-problems in the cut/paste of files model,
and I agree its sort of flakey on a lot of points (most troubling to
me is the "where are cut files" problem). But people are already used
to these quirks in Windows, and Nautilus, I believe, follows Windows
is handling these situations. So its not like we're doing anything
unexpected.

If cut/copy/paste of files were intrusive somehow, or interfered with
other important operations, I would probably agree with you Greg. But
because its sort of a latent feature, but what that lots of people
expect, I think we should have it.

(Josh also rightly points out that *lots* of people requested this
feature. It was one of the most complained about Nautilus issues,
right after performance. Users don't always suggest the right
solution, but if they're complaining en masse something is probably
seriously wrong, and often what they want is the right approach, since
its what so many people expect)

josh: not claiming my job is to decide UI; FWIW, I agree that the
basic model is broken. 

But if I've read enough of the lists and have been around for enough
of the nautilus history to know that the answer is 'doing it any other
way causes riots in the streets.' It doesn't seem unreasonable that in
cases where the issue is that clear that I act on that. Nor is it
unreasonable, of course, for folks to reopen on me after I act on that
experience; like you say, it's not my job, so no offense taken if that
occurs and I hope none given.

(FWIW, I think Louie is doing the right thing to address as many bugs
as he can to keep the noise level down)

can someone properly rename this bug so that other nautilus bug
hunters will have a clue as to what its about.

How's that?

: )

Josh

i think the only confusing item is cut. Perhaps we could remove cut,
and instead have an operation called "move."  so you make the
selections, choose move, and than use paste.

That doesn't sound that great either....uggghhh 

Created attachment 9042 [details]
some comments from a coverstion i had with greg on irc and from the nautilus-list

No one has come forth with code. No one has come forth with a concrete
proposal for an alternative design. I'm moving this off to NEEDINFO
and "future" so I don't have to keep looking at it as I try to sort
and triage bugs.

I don't know what a concrete proposal would be. Dave attached an
explanation of how this could work.

Brief summary:

Remove Cut/Copy/Paste from the file operations.
Add a Pick Up operation.
  Using this on a file, selected files, or either in sequence
  adds the file(s) to a list (or whatever data type)
Add three Drop commands.
  Drop Here.
    The picked up file(s) is(are) moved to the drop location.
    The list is emptied.
  Drop Copies.
    They are copied, and the list is emptied.
  Drop Links.
    Links (hard, symbolic, or .desktop) are created at the
    drop location. The list is emptied.
Add a Cancel command.
  The list is emptied. Nothing is done to the files.

For the UI: the Cut/Copy/Paste items are replaced with:

...       |
Pick Up   |+-------------+
Drop     >|| Drop Here   |
...       || Drop Copies |
...       || Drop Links  |
...       ||-------------|
...       || Cancel Drag |
...       |+-------------+


Preferably, the drop item is a conditional cascading menu as
described in bug #82162. This way the user can move or copy
files (whichever is the default) without opening the submenu.

An advantage of this is that it may also be used for keyboard
accessible drag-and-drop. (Perhaps the accessibility keyword
should be added.)

jfleck I would like to keep this bug open just to keep it on my radar.
Its something i'm interested in thinking about, but really need to put
time into. Anyway this bug is very future, so we have alot of time to
think about it.

I'm going to reopen this as I think the point is valid and that we
should consider these type of major ui changes in the future.

Here is an important differnce between the two models which has not
been mentioned, afaik. I think it may actually be the most important
difference and the clincher for moving to Pick Up and Drop.

(From my email to usability@gnome.org)

With Cut/Copy/Paste, you are committed to a particular action well
before completing it. If you have Cut and when going to paste you
realize you actually wanted to Copy, you have to either go back
and Paste where you Cut or you complete the action and Copy back
to the original location.
                                                                     
         
With Pick Up/Drop, you can defer the decision until you complete
the action.


There is also the matter of accessibility which Bill Haneman
expresses well in:
http://mail.gnome.org/archives/desktop-devel-list/2002-November/msg00248.html

Setting GNOMEVER2.3 so that this doesn't totally get forgotten.

Please also read my comments to bug 87330.

One thing that I haven't heard mentioned as a benefit of pick up
and drop is how it correlates with drag and drop. To me pick up
and drop is mearly an extention of drag and drop. It allows you
to drag files to a new location without having to keep the mouse
button down.

To me this seems like a great way to solve the problem that seth
has mentioned a few times for the need to have two windows open
at the same time when doing file operations.

Also, on the list, there was a good suggestion made to change the mouse
cursor to indicate that there is currently something picked up.

I have an idea for a variation of pickup and drop: 

* select files to pick them up (as you would before a drag and drop
between windows, and for a X-style text copy-n-paste) and drop them
from a menu (move/copy selected files to here). Advanced users could
choose to middle-click to paste files like the X-style text
copy-n-paste (but should files behave like text?).

* selection would be _toggled_ by clicking or dragging a lasso around
files (not sure if this is compatible with a single-click open style,
but I'm not sure if single click is any good anyway) and cancelled
from a menu (as well as with a keybinding; ESC?).

* selected files would persist (ie: stay selected between
directories/folders/whatever) until cancelled (manually or by menu).
This allows moving or copying (or maybe even other file operations)
from multiple sources from only one window.

I think this seems to map fairly well with current drag-n-drop and
cut-n-paste functionality and should be able to be made interoperable
with other filemanagers etc.

Problems would include:

* dealing with hierarchies (say, if you selected some items and then
their parent - though really, selecting a parent would select all
children - I want to get you thinking about possibilies I've missed ;)

* dealing with permissions (like a mixture of rw and ro files - mostly
a ui issue - how do you want to inform the user?)

I'm sure this is not the best solution, but I thought I might take
some ideas to a logical conclusion in the hope someone might come up
with something good ;)

> What happens if I cut one file then cut another and paste?

It could ask if you really want to delete the file. Actually, it would
be nice if cut/cut/paste always gave a warning when it cause loss of
lots of data.

On Windows 2000, a cut item is shaded (faded), and then unshaded if I
cut another item instead. That shading would help lots in Nautilus.

Do not warn about loss of data, just do not lose data! I admit that I have not
read the HIG, but really no operation should be allowed to lose data (with the
sole exception of emptying the trash).




I think a file or any other object (text, image...) should be treated the same. 

Either by, select object(s) and declare action, thus action is in a "here"
context, "copy to here", "move to here". No commitment.

Or by cut/copy objects and then paste. If the objects are files just put them
(or the copies) in a temporary directory (named limbo or something). This way
they are never lost. This directory are then scanned to supply the context menu
with objects to paste. Mosly familiar.

From the users point of view, copy, move or link is an atomic operation. i.e. "I
want to copy that file" and not "I want to read("copy") all of this file here
and write it down there(paste)". It's unlikely someone changes his mind about
the nature of the operation between the two steps, so I don't really see this as
an advantage of the "pick up" system. This also implies that unfinished or
reassigned "Cut" operations should not do anything at all.

Windows breaks up that atomic operation into two unrelated decisions.
a) "Copy" or "Cut" the file?
b) "Paste" (as file) or "paste as link"?

There is little sense in breaking it up that way. It's probably for historical
reasons (the concept dates from before links were introduced to windows?).
Taking a second look at it, it's even a broken concept. What happens if I cut a
file and paste it as a link? (I don't have access to a Windows machine, so I
can't verify what happens :/)

I think the easiest model would be to split it like this (basically what was
said above):
a) "Mark" or "Pick up", whatever is better. (I'm not a native speaker)
b) "Copy here", "Move here", "Link here"

This concept seems nice for file operations and doesn't require an answer to
what happens to "cut" files that were never pasted, but I'm not to sure how well
it suits an editor (assuming you want to stay consistent between different
application types). And it's still unclear to the user what happens if multiple
files are "marked" individually.

Well, my 2 cents...

If ain't broken...

I'd suggest that Nautilus doesn't need to rewrite the whole concept of moving
files around. The only thing that it needs is *visual feedback* of the current
state of the Cut/Copy operation:

1 - Select files
2 - Select "Cut" or "Copy"
3 - The selected files get an emblem showing that they are selected for the
operation (easy to do, the code for emblems is already there!)
4 - Select "Paste" - the files get copied/moved, and the emblems disappear.

If you really want a paradigm shift, instead of the Pick-up names, I would go on
with some names more familiar:

* Select for movement
* Move
* Copy

Move and Copy should act on the current cursor selection, or when this is empty,
on the files "picked up" by the last "Select for movement" operation.

This bug is still valid. Please get rid of this broken cut/copy/paste metaphor
in nautilus (if only just in spatial mode)!

(In reply to comment #2)
> Does the mac use cut, copy and paste as well?

It does, though:
* Cut appears to always be greyed out
* Copy says "copy 'Filename'" or "copy n items"
* paste says "paste items"

Perhaps these more explicit commands make it clearer?

I don't think that using mouse actions as menu commands is a good idea. A drop is a drop: it's something you do with the mouse (or with access keys).

Rewriting the metaphor will not help, as most users now understand cut/copy/paste, and a lot won't understand this alternative enough to make good use of it. Furthermore, it would be inconsistent, as cut/copy/paste is used in other gnome applications, as well as non-gnome ones such as libreoffice, firefox and most applications where such actions might need to be taken. A better approach would be better visual feedback, and maybe the extra options people have been suggesting, but within the framework of the traditional metaphor. So "paste", "paste but leave original" (for if you cut but have changed your mind) "paste link to original" etc.

About visual feedback, nautilus's status bar make it clear "n files will be moved if you use the paste command" if you just cut files; and that they will be "copied" when you jsut use copy. The Copy/Cut/Paste model is also well known and proved its efficiency.

Closing this a NOTABUG.

If you still think the copy/paste model needs a rework, please file another bug with a useful/descriptive title and examples of its weaknesses. Valid suggestions like comment 31 should go in a separate bug report.

Thanks