Re: [platform-ui-dev] RFC: Cut, Copy, Paste Proposal (end date = 12/03)

["Mike Wilson/OTT/OTI" <Mike_Wilson@xxxxxxx>]

"Cut from the tree" would only be something we should encapsulate if the tree widget itself provided this functionality, and even then only if we believe that it was likely to be provided in a compatible way on a significant number of the platforms and that we believed it could be emulated on the others.

Also, I think it's important to actually check what the other window systems do before you make decisions about this. For example, the linux I am running on my desktop doesn't support the Cut operation in the file explorer at all (probably to avoid the very problems you are running into).

McQ.

"Nick Edgar/OTT/OTI" <Nick_Edgar@xxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx 11/29/2001 11:01 AM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-ui-dev] RFC: Cut, Copy, Paste Proposal (end date = 12/03)

Also, is the visual indication of cut the same on all platforms?  This may 
be something that SWT needs to encapsulate.  Even if it is the same, it 
might be better to encapsulate it in SWT or some JFace utility so that 
clients don't do their own funky look and feel.

Nick





Nick Edgar
11/29/01 10:52 AM


        To:     platform-ui-dev@xxxxxxxxxxx
        cc: 
        Subject:        Re: [platform-ui-dev] RFC: Cut, Copy, Paste Proposal (end date = 12/03)

Sure enough!  For some reason I thought it was doing more.
It would be nicer if SWT had an attribute for this, though, since it would 
be much simpler for clients.  Otherwise every client needs to do more 
image resource management, thereby making leaks more likely.
I believe that it works this way in the Windows ListView . 

In any case, we would still need the callback for when the cut gets 
completed or canceled, so we can restore the image or attribute.

Nick





"Mike Wilson/OTT/OTI" <Mike_Wilson@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
11/29/01 09:54 AM
Please respond to platform-ui-dev

 
        To:     platform-ui-dev@xxxxxxxxxxx
        cc: 
        Subject:        Re: [platform-ui-dev] RFC: Cut, Copy, Paste Proposal (end date = 12/03)


On windows, the only visual indication that a cut is in progress is that 
the icon associated with the object being cut is set to a "greyed" 
version. SWT support is not required to do this. 

Aside: It seems like a fairly complex system is being designed here. Do we 
have the task model data which indicates this would actually be useful to 
a significant number of users? 

McQ. 




"Nick Edgar/OTT/OTI" <Nick_Edgar@xxxxxxx> 
Sent by: platform-ui-dev-admin@xxxxxxxxxxx 
11/28/2001 04:09 PM 
Please respond to platform-ui-dev 
 
        To:        platform-ui-dev@xxxxxxxxxxx 
        cc: 
        Subject:        Re: [platform-ui-dev] RFC: Cut, Copy, Paste 
Proposal (end date = 12/03)


Some of my points below have already been mentioned, but I'm including 
them anyway.

- It's not clear that ResourceTransfer should carry the markers or other 
metadata for the resource.  If I copy a .java file, I don't want its 
compilation problems to come with it.  I may or may not want its 
associated tasks.
Should probably separate the two, allowing the user to first copy the 
resource, then copy any tasks if desired (copying problems still doesn't 
make sense, since they are derived from the content by the compiler). 

- Paste Special support is fairly common if you want to transfer some 
attributes but not others (e.g. content vs. formatting).  Not clear that 
Navigator and Tasks need this though, although this might be an approach 
for handling metadata.

- Using the full path for the TextTransfer for the selected resource(s) is 

not necessarily the best choice.
In the UI, we generally present full paths without the leading slash (e.g. 

MyProject/MyFolder/MyFile.txt), since the root of the workspace is not 
necessarily a useful concept to the user.
Depending on the context, it may make sense to use either the full path 
with leading slash, the full path without leading slash, the simple name, 
or the location (actual file name).
The user may expect filesystem-based separators as well, not just forward 
slashes.
If we do have to decide on a default, my preference would be full path 
without leading separator, with forward slashes.

- The text used in the task list drag and drop is not very user friendly. 
It was originally more for debugging purposes than to be useful to end 
users, so I do not recommend using it.  We should come up with a better 
human readable representation, and use it for both CCP and D&D.
One option would be tab-delimited text, since this can be pasted nicely 
into spreadsheets and tables in word processors.  Even better would to 
associate RTF for a table, as well as plain text.  For example, try 
copying a range of cells in Excel, and pasting them to Word, WordPad, and 
NotePad (and vice-versa).
I'd like to see the task list work like this.
It might also be nice to allow tasks to be pasted into the task list from 
a similar format (but not problems).
Likewise for Bookmarks and Properties.

- We will also need support from SWT for visually indicating a cut/move in 

progress, in Tree and possibly other widgets (Table for task list). 
Compare with MS Explorer, which dims the item being moved.
If we don't have visual feedback for cut, it will be very confusing.
Is this even possible on other platforms?

- Esc cancels the Cut in MS Explorer.  We have no way of hooking this in 
SWT currently (hooking Esc as a global accelerator breaks other areas such 

as code assist and rename in Navigator).

- There are accessibility issues here.  You can't currently deselect or 
multi-select in a Tree using keyboard only.  There's an SWT PR for this 
already.  We need to ensure that whatever solution we come up with is 
workable using keyboard only.

- If copy (or cut) works differently for projects than for other items 
(e.g. pops up a dialog for projects, but not other items), then we should 
not use the same action.  It would be preferable to disable copy and have 
a separate Copy Project item on the context menu.

- Regarding the confusion over what gets copied for markers, the clipboard 

supports multiple formats, so it should be seen as copying all of: the 
marker itself (MarkerTransfer), its text (TextTransfer), and a table 
representation (RTFTransfer -- see above).  It's the client doing the 
paste who gets to decide which format it prefers.

- Need to ensure ResourceTransfer and MarkerTransfer support multiple 
items, if they don't already.

- I concur with Simon that we should support copying resources between 
separate workspaces.  This means that the ResourceTransfer must encode not 

only the resource's path but also its location, and possibly an ID for the 

workspace (e.g. if I cut a /A/B in workspace 1 and paste it to /C/B in 
workspace 2, I want to delete /A/B from workspace 1, not workspace 2 if it 

also has /A/B; this may just work out if it's the cut handler which does 
the deletion though).






"Karice McIntyre/OTT/OTI" <Karice_McIntyre@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
11/26/01 05:31 PM
Please respond to platform-ui-dev


       To:     platform-ui-dev@xxxxxxxxxxx
       cc: 
       Subject:        [platform-ui-dev] RFC: Cut, Copy, Paste Proposal 
(end date = 12/03)


Please provide comments on the following proposal by 12/03.  This is not a
call for committers to vote.

(See attached file: cut-copy-paste-proposal.zip)



_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev






_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev