Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] RFC: Cut, Copy, Paste Proposal (end date = 12/03)

My [SA: comments] below

Simon :-)

--------------------

Background

<<snip>>Not all ISVs who implement Cut, Copy, Paste may want to or will be
able to use a conceptual clipboard to perform these actions<<snip>>
[SA: What is this conceptual clipboard? Is this something provided by
Eclipse? Or is this another name for the System Clipboard? If not, what is
different about it compared to the System Clipboard (and why would someone
use it over the System Clipboard)?]


Proposed Changes

<<snip>>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<<snip>>
[SA: What are the reasons why I can't copy a resource (with meta data) from
one workspace to another? That is, why can't I do a ResourceTransfer
between workspaces?]

<<snip>>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<<snip>>
[SA: I could Cut a project from one workspace and Paste into another...in
other words, remove it from one workspace and place it in another -
wouldn't that be valid? If I paste it back into the same workspace, then
nothing happens...just like in the MS explorer when you cut a file and
paste it back into its original directory.]

[SA: We should look into removing the Move operation all together from the
Project context menu also. This is an action that will be performed very
rarely, so why clutter the context menu? It would be better if this
operation was done from the Properties dialog. If we are leaving this Move
action, then maybe we could at least change its label to be more specific
what it will be doing e.g "Change Location"]

Problems with Solution

<<snip>>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).<<snip>>
[SA: Not sure if I understand this point properly. Core does not allow two
projects to have overlapping locations. So pasting a copy of the project
with the same location as the source project will fail at Core level. If
the source project uses a "default" location, then the project copy can be
created with a "default" location and Core will be happy since they will
not overlap. The problem is when the source project has a "custom"
location, what location will the project copy have as it cannot simply use
the "custom" location of the source project (remember, Core allows no
overlap)? One option is to have the project copy use a "default" location
which the user can change later on. We would need to come up with some use
cases here to determine what the proper behavior should be.]

<<snip>>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<<snip>>
[SA: Each view should place on the clipboard all formats that it can
support. So for the Task view, it should place a MarkerTransfer (say I want
to copy a task from one workspace to another) and a TextTransfer (copy to a
external text editor). We could support a Paste Special that provides the
user with the possible transfer available that the destination understands
(see MS Word for an example using different Clipboard selections). In just
a normal Paste, the destination usually understands few different transfers
and looks for these on the clipboard based on some order. For example, MS
Word looks for MS Doc transfer first, then RTF, then Plain Text last - sort
of the order a user would expect.]




Back to the top