Community
Participate
Working Groups
Server side for file copy move was implemented in 0.2-M4. We need UI for this.
An option to drag'n'drop a file would be nice. Holding Ctrl to copy, move otherwise.
(In reply to comment #1) > An option to drag'n'drop a file would be nice. Holding Ctrl to copy, move > otherwise. Tomasz, I agree that would be cool but I'm going to be more low tech in my first pass. I plan to enable a selection-based action that gives you a popup which lets you choose the target folder. (I looked at dojo d&d and while it handles the ctrl/copy or move situation nicely, it's based on literally moving the dom elements around, so it would be some work to get this working in nav-table). It will come later...
(This message is mostly for Gosia...) I've now stubbed in the commands for move/copy into nav-table. It doesn't do anything yet, but what this proves is that the nav toolbar is now "selection service aware." It sets up a special dom node for showing bulk selection actions. I created a separate node so that we can recompute bulk selections on the toolbar without having to update the non-selection dependent part of it. The tree nav is not working yet, I want the move/copy to be object contributions in the menu rather than in the top toolbar. Before I get too tied up with this, I want to work on bug 337867 and get the file command extension looking more like we want.
cc'ing John. John, I noticed on the milestone plan (http://wiki.eclipse.org/Orion/Milestone_Plan) that you were planning to do the fileClient part of this work. I stubbed in some methods in fileClient for copy/move and I'm calling them from the UI. They currently just log the source and target locations for the operation. I was hoping you could take this further while I continue on the UI. I wasn't sure about the paths (whether hostname was required, etc.) I did strip off the query parts of the paths but that's it so far. UI-wise, I've hooked in the move/copy commands to the bulk actions menu and currently just hook up a submenu that gives you the favorites (directories) which can be targets. The plan is to also provide choices based on the selected items and navigator root. Then the user can open a dialog if we haven't guessed the most common locations. So on my to-do list is still: - add the parent/child directories of all selected items to the targets list - consider adding move/copy as a single-item contribution the "more" menu for local items - implement a prompter that will let let you pick any folder among all the workspaces I think I can get most of this done for M6 except that - the prompter may be ugly or barely function (ie, type in a path). - there are lots of cases to catch when the user tries to move or copy things that reside within each other, etc. Not sure how robust the target validation will be.
Another to-do in the UI. We currently don't cache the checkmark selections in the nav table. Since we now want to update the table as the server completes the move/copy operations, we need to start keeping the selections. I think we should only remember the ones that are on page (rather than keeping an additive cache that remembers everything you've checked as you've drilled up and down the breadcrumb).
(In reply to comment #4) > cc'ing John. John, I noticed on the milestone plan > (http://wiki.eclipse.org/Orion/Milestone_Plan) that you were planning to do the > fileClient part of this work. I stubbed in some methods in fileClient for > copy/move and I'm calling them from the UI. They currently just log the source Ok, great. I'm doing significant rework of the fileClient so I thought it would be easier for me to do this part. I'll move this up my priority list now that I know you're actively looking at it.
slight progress here on the UI-side, but still needs a lot of work. - putting move/copy in the object contribution (per row) was a performance hog because we were computing valid targets for all visible items up front. Opened bug 338887 (the specific problem) and bug 338888 (a more general issue as we add more plug-ins with nav commands). - computing valid targets is reasonably helpful when you have a folder or file selected at the main level of nav. When you've expanded a ways down, we really need to consider the tree root and all its visible descendants. Simply doing parent, parent's siblings, children isn't enough - the most common case I use is copying a file in place. We will need to generate a "copied" name for the file, this isn't done yet. - I was hoping to display full paths to help with indention/nesting in the submenu. But full paths have the problem where the implementation workspace name shows. Need some code to traverse the path and substitute the workspace name for the implementation path, but retain the rest of the segments. (Yuck - John, should we have some kind of util helper for this? I hate that the client has to know about this.) - still need some kind of lightweight dir prompter I'll be out tomorrow, but will see how John does on the fileClient side of this. If that gets implemented, I'll try to put some more time in on the UI.
(In reply to comment #7) > - I was hoping to display full paths to help with indention/nesting in the > submenu. But full paths have the problem where the implementation workspace > name shows. Need some code to traverse the path and substitute the workspace > name for the implementation path, but retain the rest of the segments. (Yuck - > John, should we have some kind of util helper for this? I hate that the client > has to know about this.) Yes, not nice for client to deal with this. I even dislike the concept of "full path" showing up in the UI. Paths on the web are always relative to something, unless they are full URL, and in our tools the user isn't necessarily familiar with the URL of a given file. What the server API provides today is parent links, which we use for example in the breadcrumb for logical upwards navigation: http://wiki.eclipse.org/Orion/Server_API/File_API#File_Parents Do you see this displaying full paths as a short term thing until we have a nicer UI with either a tree or DnD to select the destination? Another alternative would be a dialog with a flat list of hyperlinked projects, and the user tunnels down through the links to find the destination they want. > I'll be out tomorrow, but will see how John does on the fileClient side of > this. If that gets implemented, I'll try to put some more time in on the UI. I have committed/pushed the fileClient support. I didn't see any way to test it via the UI so it is currently untested. One detail to point out, is that copy/move both support renaming the file/directory at the same time. For example if you copy a file to the same directory, you need to supply the new file name. For the JS API, I have made the destination file/directory name optional. If not specified it will use the same name as the source. Therefore this JS API can be used for both copy/move as well as rename and copy+rename. I don't know if you were planning to tackle rename as part of this, but the option is there anyway.
(In reply to comment #8) > I have committed/pushed the fileClient support. I didn't see any way to test it > via the UI so it is currently untested. One detail to point out, is that > copy/move both support renaming the file/directory at the same time. For > example if you copy a file to the same directory, you need to supply the new > file name. For the JS API, I have made the destination file/directory name > optional. If not specified it will use the same name as the source. Therefore > this JS API can be used for both copy/move as well as rename and copy+rename. I > don't know if you were planning to tackle rename as part of this, but the > option is there anyway. John, it's testable as is (but doesn't seem to work.) I tried the following. - Create a project (so you aren't messing with your real work). - create Folder1 - create Folder2 - create a file "test.txt" in Folder2 - select (checkbox) the file - select More actions->Move to->Folder1 File is not moved.
(In reply to comment #9) > I tried the following. > - Create a project (so you aren't messing with your real work). > - create Folder1 > - create Folder2 > - create a file "test.txt" in Folder2 > - select (checkbox) the file > - select More actions->Move to->Folder1 I missed the "More actions" at the top.. that menu only seems to appear when you checkbox something, which makes it a bit hard to discover. In any case, there is a path manipulation bug on the server that somehow didn't show up in the server tests. I am working on it.
(In reply to comment #10) > In any case, there is a path manipulation bug on the server that somehow didn't > show up in the server tests. I am working on it. Now fixed. Everything seems to be working quite well now!
marking fixed, but realizing more work is needed post-M6. I opened these bugs for the future: Bug 339144 - drag and drop Bug 339145 - dir prompter Bug 339147 - validation strategies, name collisions and rename
(In reply to comment #5) > Another to-do in the UI. > We currently don't cache the checkmark selections in the nav table. Since we > now want to update the table as the server completes the move/copy operations, > we need to start keeping the selections. I think we should only remember the > ones that are on page (rather than keeping an additive cache that remembers > everything you've checked as you've drilled up and down the breadcrumb). opened bug 339450 for this one
