On Tue, 2003-04-01 at 01:25, Wesley Leggette wrote:
> Regarding Pick up and drop, I think the semantics are no better. What
> happens if you "pick up" one object, then another, and then drop? It
> would defy all expectations to "drop" both of them at the new location
> if this is simply a change in cut, copy, paste. So assuming that that it
> would work this same way, the change in terminology is pointless. We all
> know what cut, copy, and paste mean and it's more than logical to assume
> our users do to.
I think that if you can dig through bug 77293 you will see that they are
not the same. As well as that, copy and paste in a file manager is not
something that the majority of people use. In fact I've never seen
anyone except the most advanced users use it, and even for them it took
getting used to.
For me this is the major reason why we can change this: it is a broken
metaphor BUT it is not widely used enough for changing it to be a major
problem AND for users who are used to copy and paste it will take them
very little time to get used to it. To me it embpaces and expands the
copy and paste idea - but is similar enough to be non-disruptive.
The major difference is that you decide what you are going to do with
a "picked up" file when you are dropping it and not when you are
"picking it up" which gives much greater flexability and would also go a
long way to making nautilus's context menus more sane.
>> From the bug report, a proposal:
"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 lisfile:///home/sisob/.gnome2/panel2.d/default/launchers/blah-001a326f8b.desktopt 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.)"
>> another point from the bug:
"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.
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";
>> end of bug comments
Personally I don't think that this implementation is perfect, but it's a
lot better than copy and paste and I hope that we can improve these
ideas in the future.
> But of course there is a utility for remembering multiple cuts and
> placing them all in the new paste spot. But users would have to be able
> to easily remember what they have currently cut (some sort of cursor
> tag-a-long that shows the icon's they are carrying and allows them to
> drop all or some of them unchanged?). If this sort of behavior were
> implemented, "pick up" and "drop" would make a lot of sense, and since
> it's different that traditional cut and paste, the name change would be
> appropriate.
you see - now you're thinking properly - we don't have to copy OsX or
Windows or KDE or anyone - let's make gnome really Useful and inovative
;) I agree that knowing what is currently picked up is left out from the
current proposal and that would need to be delt with.
> And hey, we could always have a preferences toggle between
> the two modes of operation.
Good no! /me points to havocs paper
--
.--= [ MArk Finlay - sisob ] =--.
[ Gnome User's Board : www.gnomesupport.org/forums ]
[ Public Key: http://evolvedoo.sf.net/sisobatericomdotnet.asc ]
Attachment:
signature.asc
Description: This is a digitally signed message part