Re: [PATCH] Context-sensitive paste

[Marcello Raffa <mrooth tiscalinet it>]

On Thu, 30 May 2002 20:08:42 -0400 (EDT), you wrote:

> > 1) when the current selection involves more than one object, the paste
> > menu item is accordingly disabled in clipboard_targets_received, since
> > we can't assign a meaning to trying to paste to more than one
> > destination at once
> > 
> > 2) when the current selection involves only one object, then pick its
> > uri as the destination for the move/copy action and set the paste menu
> > item label to "Paste Into" (not sure if "Paste Inside" would be
> > better; in bug #76952 "Paste Here" is suggested, but see below); note
> > that clipboard_targets_received again disables the paste menu item if
> > the selected object is not a directory
> > 
> > 3) when the current selection is empty, assume that the user wants to
> > move/copy the clipboard contents in the current location (which is
> > what nautilus is always doing right now) and set the paste menu item
> > label to "Paste Here"
> 
> I think it could be confusing to users. It's sort of different from the 
> common cut and paste meme. Windows does it a bit differently, you only get 

I don't know what you mean by "common" cut and paste meme, but I do
believe that the current behaviour should be fixed because, unlike
other menu actions, it's not context-sensitive.

Both "Cut file" and "Copy file" act depending on the current
selection. Just below them there is currently a "Paste file" menu
item, and this is misleading because the user gets to think that it
will likewise act depending on the current selection, while it will
paste the clipboard contents in the current location, regardless of
it.

Let me propose an alternative solution to this issue, which is surely
better than the one I first proposed.

The current context-insensitive "Paste file" menu item should be
renamed to "Paste here" (as short for "Paste in the current location")
and put somewhere farther in the context menu, beyond a new separator,
surely not where it is now. It would always do the same thing (that
is, what nautilus does right now) and would be always enabled, at
least as far as there's something to paste sitting in the clipboard.

Then, for convenience of use, a context-sensitive "Paste Into" (or
whatever may fit better as far as lexicon is concerned, as I said I'm
not sure), could be added just after "Copy file". This should be
enabled if the current selection is single && the selected object can
accept copy/move actions as a destination, and disabled otherwise.

In this way, when the user pops up the context menu he will be
presented with two choices, "Paste Into" (sometimes disabled,
according to the current selection) and "Paste here" (always enabled
and put in the lower side of the menu), which I think is by no means
confusing.

> to paste into if you user the context menu on a specific icon, and if you 
> use paste from the normal menu it always pastes into the current 
> directory. That sounds like a better way, but I'm still not sure I like 
> it. 

Currently the cut, copy and paste menu items in nautilus's edit menu
act just like those in the context menu, so I think that the proposed
split should be adopted there too.

> > 4) the patch also makes a one-line addition in fm-icon-view.c, to
> > empty the current selection when the user right-clicks on the
> > background of the view workspace instead of right-clicking on one of
> > the currently selected objects; this is not strictly needed, but I
> > think it's more intuitive and click-saving (right now pasting in the
> > current location requires two clicks if the selection is not empty)
> 
> This one I don't like at all. Loosing your selection by misstake is 
> very irritating, and right clicking on the background is pretty common. 
> Not to mention the fact that it is easy to miss an icon by misstake.

Even if I don't find it that easy to lose one's selection by mistake
(unless one is doing things in a hurry), since nautilus highlights the
currently hovered icon (and the text too if you're in
single-click-activate mode), I guess this is more of a subjective
matter, as it just involves behaviour, not semantics.

(On a personal note, I'm used to the windows explorer way of popup
menus management and therefore I find it comfortable. Perhaps emptying
the selection on background right-click could be made an option, if
it's worth it ... I'm not sure about it. Otherwise I will just get
used to first clicking in the empty area of the workspace.)

Bye and a good day.

-- 
Marcello Raffa
mrooth @ tiscalinet.it