RFC
Cut Copy Paste - Draft 1
Summary
The Eclipse workbench defines global actions for Cut, Copy, and Paste. The
active part in a workbench page is able to supply an action handler for these
actions and thus define what they do. The default text editor and the java
editor perform the expected textual cut, copy, and paste (to and from a conceptual
clipboard) in response to these actions. However, in the resource navigator
cut and paste are not implemented while copy opens a dialog to perform a copy
operation. The workbench needs to define the semantics of cut, copy, and paste
and extend the use of these actions throughout the workbench. These actions
should be regarded as the keyboard equivalent of drag and drop.
By Randy Giffen and Karice McIntyre,
OTI
Last Modified: November 23, 2001
<Greg>
- I agree with overall direction/intent.
Issues not covered or unclear
- When a cut operation is in progress will the icon
be shadowed/grayed - or will it be immediately removed
- If a cut does not immediately remove it, can I cancel
the cut (e.g. using escape)? I vaguely recall SWT has grief with delete and
escape - but imho if this is the case they earn a pr.
- Will our text editor copy text in a rich form including
colors etc. Thus if I copy java code and paste it to word it would look identical
including colors?
- I assume I can copy a project, folder, or file between
two running versions of eclipse - this would be bogus if we can't
- Is there any override confirmation if the paste will
oveeride an existing file.
- When an object has multiple formats on the clipboard
what order do we look at them for. For example: Presumably a task view for
example would look for a marker format first, failing that it could take a
text format and create a task from it?
- If I copy a resource do its markers go with it. Presumably
not since they are not actually part of that resource.
However I assume metadata that is effectively part of the object (e.g. project
natures) is copied.
- Suppose I copy a problem from the task list. Can I
paste it back in later - presumably not - but there is not mention for deny
cases
- I assume the behavior will be the same on all platforms.
- Mcq indicates Linux does not have cut on its file
explorer. I'm not a linux person & don't have it in front of me - but
this sounds rather inconsistent with how it likely works in other places not
related to files. Also keep in mind we are look at it for more than just files
so using the file explorer is not a true comparison. In addition I would argue
that if the linux model is inconsistent (I need to go look) then that's simplicity
for the sake of coding not the user.
</Greg>
The Details
Problem
The use of a conceptual clipboard to support the actions
of Cut, Copy, and Paste is a powerful UI feature that is currently underutilized
in the eclipse workbench. Moreover, there is a strong correlation between
this feature and the Drag and Drop feature. In general, where one is supported,
the other should be supported as well. Currently Drag and Drop is supported
in places (ex. resource navigator) where Cut, Copy, and Paste are not. To
compound the problem, in the resource navigator we are using the copy global
action to open a dialog based copy that is not clipboard related.
<Greg>
Agreed - dialogs should not be opened
on copy. I think Nick (NE) suggested dialogs on paste to refactor but I would
be concerned this would be too "in your face" for users.
I am ok with it in the exception case
(e.g. data overwride like file conflict) but each time ... that can get tedious.
We need to encourage ISV's not to do
this. It's too bad there is no way to prevent this - e.g. by the workbench's
copy doing all the actual work and simply asking for the target part to just
supply the transfer format. That is, the targeted part doesn't actually get
to control the entire action. (of course that would also be a breaking change)ss
</Greg>
Background
The clipboard model is fairly well understood by most users.
Frequently it is used to support text editing. Its use can be extended however,
to support the idea of putting objects such as files on a clipboard (ex.MS
File Explorer). Moving and copying files for example, can be achieved without
requiring the use of a dedicated dialog that typically is used to indicate
the destination of the operation.
The underlying clipboard support in SWT uses the concept
of a Transfer (org.eclipse.swt.dnd.Transfer). A Transfer is essentially code
that knows how to move a something on and off the clipboard as bytes (note
it may only put a reference on the clipboard such as a filename). Transfers
have a stateless singleton instance accessed via a static getInstance method.
SWT provides the following concrete types of transfers:
- TextTransfer - used to transfer
plain text
- RTFTransfer - used to transfer
text with rtf format
- FileTransfer - used to transfer
files
The workbench defines the following transfer types:
- MarkerTansfer - used to transfer
a marker
- PluginTransfer - used to support
the drop action extension
<Greg> I am not sure what this one means/does.
The name is really misleading unless its actually copying a plugin.
</Greg>
- ResourceTransfer -used to transfer
an IResource (includes path and type information)
Of course if a plugin wants to transfer an object that is
not supported by one of the currently existing Transfer classes, a custom
transfer can be implemented (see org.eclipse.ui.part.ResourceTransfer as an example).
<Greg>
</Greg>
An important point to note is more
than one type of transfer can be placed on the clipboard at a time. For example,
performing a copy in the Navigator should cause a ResourceTransfer, a FileTransfer,
and a TextTransfer to be placed on the clipboard (see Proposed Changes item
2 below for details on each of these transfer types). The enablement of a
paste action, and the type of paste that is actually performed are determined
by the target of the paste based on:
1) its state (ex. current selection)
2) the contents of the clipboard (the type of transfers
available).
A frequently requested feature is
the ability to copy a "selection as text" so that it can be used
in a text editor. The use of a simple TextTransfer makes this easy. This should
be performed by the Copy action. There is no need to define an additional
"Copy Names" action as appears in the Packages view. In the case
of a part using a standard JFace StructuredViewer, the copy action would use
the labels of the selected items as the text to put on the clipboard but this
could be customized as required.
<Greg>
</Greg>
While it is beneficial to support as "high-level"
a transfer as possible, there are cases where this can be annoying. For example
suppose one is working in an editor that supports rich text but you want to
compose a simple text note. Drag and Drop or Cut, Copy, Paste often produce
a rich text entry such as a particular font or even a table. In such cases
the user may resort to performing an intermediate step of transferring the
contents to a simple text editor to remove the high-level information.
Proposed Changes
1) Define the Cut, Copy, and Paste global actions as only
performing clipboard related actions (i.e. get rid of the dialogs currently
used for copy). All implementers of action handlers for these actions must
conform to this restriction. Of course this is a guideline that we would expect
plugins to follow/migrate to, but they will not be broken if they do not.
2) Implement Clipboard based Cut
Copy and Paste global action handlers for the Resource Navigator. These will
be API (both for instantiating and subclassing by other plugins).
These actions will support
a) ResourceTransfer within a workspace. That is, a transfer
which preserves workspace meta data such as markers and natures.
b) FileTansfer between workspaces and between a workspace
and another application. This transfer only involves the OS file or folder
(no meta data). It is similar to import/export.
c) TextTransfer of the full path of the selected resources
when performing a cut or copy.
<Greg>
Transfer (cut/copy/paste) *must* also work between workspaces - if core/swt
functionality is needed then they get the pr. Without this it doesn't it mean
that if there were two separate eclipse products installed as opposed to having
the two integrated, then it would be impossible to copy between them.</Greg>
<Greg>
Copy between workspaces is also another reason to enable copy for projects,
as well as copying them to a file explorer. </Greg>
Note: Cut will not be enabled for
Projects since there is nowhere to move them to.
The Move operation will remain for projects since it changes the location
of the project and is unrelated to clipboard cut, copy and paste.
<Greg>
</Greg>
3) Since a move can be performed
using cut and paste we would remove the Move action from the navigator. The
MoveResourceAction and CopyResourceAction classes would remain since they
are API but we would no longer use them ourselves in the workbench.
<Greg>
Agreed.
If the API
remains what will be its behavior. Will it map to the new approach, or will
dialogs result? Ideally the former
</Greg>
4) Implement a Copy action handler
for the task list that uses a TextTransfer to place a full description of
the selected task on the clipboard (identical to the description obtained
by dragging a task onto a text editor). A similar text only copy action
handler would be implemented for the Bookmarks view and the Property Sheet.
For consistency, drag of a TextTransfer would also be implemented in these
views.
<Greg>
To confirm
it means copying an object in the bookmark means copying the bookmark itself
and not copying the object it bookmakrs - right?>
</Greg>
Problems with Solution
<Greg> These don't seem so much like problems with
the solution as much as a statement of missing support from other components>
</Greg>
- Need API from SWT for Clipboard
copy vs. Clipboard move (cut). See Bug 5645 for more details.
Here is the short story:
1) Currently there is no way for
the UI to implement (resource) cut so that it works correctly when pasting
outside of eclipse (ex. paste to MS File Explorer). The problem is:
a) we have no way of indicating to MS File Explorer that it should perform
a "move paste" rather than a copy paste.
b) we have no idea when a move paste occurs and thus cannot "refresh
from local" (note that this is more than just updating the display, the
workspace must be updated).
A similar problem occurs when performing a file cut outside of eclipse
and then pasting into eclipse. We don't know that it is a move paste.
In addition the clipboard must clear itself after a move paste.
2) The problem can be solved. SWT needs to add API
to:
a) Allow us to set/detect if the contents of the clipboard are there as the
result of a copy or a cut.
b) Allow us to register a listener to be notified when a paste occurs.
This api could perhaps be added to org.eclipse.swt.dnd.Clipboard but this
remains to be worked out.
·
Copying of projects will actually require more steps then with the old dialog
solution. There are several things
we can do to copy a project using the new semantics of cut copy and paste
of resources, none of which actually require fewer steps than the current
implementation. Firstly, the
user will have to select the project (no other resources can be selected),
select Copy from the menu, deselect everything in the Navigator, then select
Paste from the menu (that 4 steps already). At this point, to complete the project copy, we can do one
of the following: <Greg> This is ok. & it's
consistent / expected </Greg>
1)
paste a copy of the project in the current location of the project (based
on assumption that most often the user wants the copy of the project to be
in the same location as the original) and be done with it. If the user wants to change the location
then they will have to perform a subsequent Move operation on the copy of
the project. This solution keeps
consistency with cut copy and paste being clipboard related (no dialogs please).
2)
bring up the copy dialog (as it exists now) so the user can change the location
of the project before the copy occurs. This breaks with the consistency of cut
copy paste being clipboard related, but requires fewer steps. </Greg> no</Greg>
·
On a more general note pertaining to views other than the Navigator, if an
implicit textual copy of the name of the selection (in the Navigator, the
names of the selected resources) is placed on the clipboard as a TextTransfer
(along with a any other applicable Transfers), the user could be confused
as to exactly what is being copied. For example, in the Tasks view when a task is selected and
the user pops up the menu and selects Copy, how does he know what is being
copied – the Task object itself or just the text? Basically, we don’t want to create confusion for the user
as to what copy actually copies in different views.
RFC
This proposal is not currently being voted on however you
should
- Provide all comments/feedback
to the mailing list.
- Clearly indicate if you are
fundamentally opposed to the proposal and provide reasons.
If you have serious concerns don't
wait until there is a vote - speak up now! Staying
silent and then casting a veto vote later isn't going to make you very popular.
RFC Termination Date
The period for comment ends 1 week from date proposal is
submitted to the mailing list.
|