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)

See <<KLM>> for answers

                    Arsenault/OTT/OTI"             To:     platform-ui-dev@xxxxxxxxxxx                                       
                    <Simon_Arsenault@xxxxxx        cc:                                                                       
                    m>                             Subject:     Re: [platform-ui-dev] RFC: Cut, Copy, Paste Proposal (end    
                    Sent by:                       date = 12/03)                                                             
                    11/27/2001 09:23 AM                                                                                      
                    Please respond to                                                                                        

My [SA: comments] below

Simon :-)



<<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)?]

The concept is using a clipboard to implement copy (currently, Eclipse does
not use this concept for copying of resources).  In the implementation, we
will use the system clipboard (provided by SWT).

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?]

Well, you can copy a resource from one workspace to another.  It is done
using a FileTransfer instead of a ResourceTransfer (drag and drop works
like this already).  My guess is the whoever implemented the
ResourceTransfer class was looking for the simplest implementation; I think
it would be a bit more complicated to serialize/de-serialize the info as a
resource with all the metadata.  If you look at the implementation you will
see that all the pertinent info is recorded for a ResourceTransfer.

<<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
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.]

In theory this is possible.  The implementation for transferring a project
to another app or another workspace is complicated (because projects have
metadata).  When Core is finished their work on importing/exporting
projects perhaps this will become an easier problem to solve.

[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"]

Noted.  Good suggestion.

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
[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.]

If you create a copy of the project an auto rename occurs.  So if you have
a project called Test and copy it, there will be a project called Copy of
Test in the same location (this is the default behavior now if you copy a
project).  This prevents name collisions.

<<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.]

Agree about placing all possible transfers on the clipboard.  As stated in
the proposal, the Navigator will put a ResourceTransfer, a TextTransfer and
a FileTransfer on the clipboard when a copy or cut is done.  BTW, Task view
already places a MarkerTransfer on the clipboard.  You can drag and drop a
task to, say, MS Word and you will get a textual representation of the
task.  Neat, huh?
The Paste Special is an interesting idea.  How do you see it fitting into
the Navigator?  Would Paste paste the textual representation of the the
clipboard contents or the actual resources that were Cut/Copied to the
clipboard (I would think the latter, not the former in the case of the
Navigator).  And Paste Special would paste the textual representation of
the selection (like Copy Names, Copy to Clipboard).

platform-ui-dev mailing list

Back to the top