[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [platform-ui-dev] RFC: Cut, Copy, Paste Proposal (end date = 12/03)
See <<KLM2>> for responses.
Likewise, I also removed chunks that I have no further comment on. But I
have taken note of them! :-)
- Need to ensure ResourceTransfer and MarkerTransfer support multiple
items, if they don't already.
What do you mean by support multiple items?
<NE> The views allow multiple items to be selected. Can multiple items be
handled in a single CCP with the current transfers?
Yes, these transfers already handle >1 resource. Example: Try DND of
multiple files; it uses these transfers and handles multiple selection.
- 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).
There's a larger issue with Cut between workspaces and between a workspace
and another app right now anyway. Apparently Windows has API that can
us (via SWT, if they implement it) whether the action was a Cut or a Copy
when a Paste is done. Likewise if we put the contents on the clipboard,
would have to tell them whether it was a Cut or Copy. Then, after the
paste happens, we get or send a callback to the OS (depending on whether
not we are the destination or the source of the Cut or Copy) so that the
original can be deleted if it was a Cut. To complicate matters, other
platforms don;t seem to have this added support. If you look at Linux
(Gnome) there is no Cut, just Copy, Paste, and Delete to do all the same
work. If this support in Windows is added then i think your concern about
possibly whacking a path with the same name in the second workspace will
inherently be taken care of. Anyway, right now we can copy files/folders
between workspaces (and projects will only come over as folders, as
mentioned before). If you Cut between workspaces right now it's as if a
Copy was done.
<NE> SWT needs to investigate Cut on other platforms.
When you say that a project copy appears as a folder copy to another
workspace, does that mean it can't be pasted in as a project, or just that
it loses its metadata? Is there any reason why the metadata can't be
preserved (adjusting for the new workspace location, of course)?
That's right, you can only paste as folders (right now anyway). Currently
the metatdata is not serialized in the transfer. I am still not certain of
all the issues with transferring a project (metatdata etc) outside of the
workspace. What would we do if we transferred a project to the file system
vs. transferring between workspaces. I am pretty sure that right now I
cannot get all the required metadata, etc to copy the project into the
destinary workspace. I think we need additional Core API to accomplish
this (they are currently working on a file format that encapsulates all the
info required to persist a project, there is an RFC on the Core page now;
deadline Dec 03). I was thinking that for now we could use the lowest
common denominator (copy project just as folders) when copying outside of
the workspace then we could fix up copy of projects once the Core api
becomes available. i was talking to someone on the core team and it sounds
like it will give us the info we need to do this.