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 my [SA2: comments] below (I only kept the points I wanted to comment
back on and removed the rest)

Simon :-)



                                                                                                       
                    "Karice                                                                            
                    McIntyre/OTT/OTI"              To:     platform-ui-dev@xxxxxxxxxxx                 
                    <Karice_McIntyre@xxxxxx        cc:                                                 
                    m>                             Subject:     Re: [platform-ui-dev] RFC: Cut, Copy,  
                    Sent by:                       Paste Proposal (end date = 12/03)                   
                    platform-ui-dev-admin@e                                                            
                    clipse.org                                                                         
                                                                                                       
                                                                                                       
                    11/27/2001 10:46 AM                                                                
                    Please respond to                                                                  
                    platform-ui-dev                                                                    
                                                                                                       
                                                                                                       




See <<KLM>> for answers



                    "Simon

                    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)

                    platform-ui-dev-admin@e

                    clipse.org



                    11/27/2001 09:23 AM

                    Please respond to

                    platform-ui-dev







My [SA: comments] below

Simon :-)

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

Proposed Changes

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

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

[SA2: Once core is done with the import/export work, we should document
whether it is possible or not.]


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

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

[SA2: The point I wanted to raise is that the location is *not* the same
for the copied project. So we need to come up with a story for this now
that the dialog will not be shown. Like I mentionned in my first comment, a
project using a "default" location is no problem because the copied project
will also have a "default" location (note that each location will be a diff
directory in the workspace...Core does this for us for free). The more
interesting problem is when the source project has a "custom" location. The
only option I see here is for the copied project to have a "default"
location, it cannot use the "custom" location of the source project, Core
will complain.]

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

<<KLM>>
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).

[SA2: I was expecting Task view to place a TextTransfer (to get textual
representation for apps that know nothing about markers) and MarkerTransfer
(to get all the marker info so it can be pasted somewhere else as another
marker, kinda like ResourceTransfer will include not only the file but the
meta-data so it can be pasted as an resource somewhere else). Anyway, not
too worried about this...

I would expect the paste action of a view to do the right thing ;-) A view
may know how to handle different clipboard formats (transfers). The
standard is to pick the "richest" format from the clipboard that the
destination understands. In the case of the nav, if there was a resource
and file format, it would pick the resource format for the paste action as
it is "richer" (contains not only the file, but the meta-data too)

Paste special is more of an advance feature (in my opinion). The view
presents a dialog with all the formats on the clipboard that the view
understands. The user can then choose which one they want to use. Try this
out with an application that has a Paste Special action (like MS Word). In
the case of Nav view, it probably does not make sense to support a Paste
Special. It can only really understand two formats: Resource and File. I
can't think of a use case where a user would want to choose File instead of
Resource if both formats were available. So I guess what I'm saying is
Paste Special should only be added if a view really has a need for allowing
the user to choose the format to paste from.]




Back to the top