Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #222404 +++ From bug 222404 comment 1: We need extra events in RSE such that a listener gets notified when a remote item is moved or copied. This is needed in order to maintain properties attached to a remote object, see also bug 224199. Events for MOVE and COPY should hold both the source path and the destination path of the remote object as well as the subsystem(s) involved. Since MOVE can be seen as a variant of COPY, it might also be possible to handle both cases with a single event. I need a way to handle setting/managing properties for remote files.
Currently, when a move operation takes place we fire the following events: SYSTEM_REMOTE_RESOURCE_DELETED SYSTEM_REMOTE_RESOURCE_CREATED These are the combination of a delete, followed by what we used to do in the old copy action, which is just this: SYSTEM_REMOTE_RESOURCE_CREATED However, the old copy action is no longer used (in base rse), since we replaced it with the clipboard copy/paste actions, which make use of SystemDNDTransferRunnable. At the end of that operation we fire the same event: SYSTEM_REMOTE_RESOURCE_CREATED Our views make use of these events to update the tree and table. Given the time constraints of this release, I'm a little apprehensive of simply replacing these event firing with new events: SYSTEM_REMOTE_RESOURCE_MOVED SYSTEM_REMOTE_RESOURCE_COPIED Perhaps, we could initially fire the new events on top of what we already fire. In that case, for move we'd have: SYSTEM_REMOTE_RESOURCE_MOVED SYSTEM_REMOTE_RESOURCE_DELETED SYSTEM_REMOTE_RESOURCE_CREATED In that case, for copy we'd have: SYSTEM_REMOTE_RESOURCE_COPIED SYSTEM_REMOTE_RESOURCE_CREATED or we could do the following: For move: SYSTEM_REMOTE_RESOURCE_MOVED For copy: SYSTEM_REMOTE_RESOURCE_COPIED However, there would be more work involved to change the event handling for these cases. What do you think?
Could we just keep the existing events and add new fields to them: SYSTEM_REMOTE_RESOURCE_DELETED --> Add "Moving to: absolute path" field SYSTEM_REMOTE_RESOURCE_CREATED --> Add "Copied from: absolute path" field When the new field is null, it's a plain creation / deletion without any move/copy operation.
Created attachment 93820 [details] patch for describe remote events via operation field Here is a patch that adds an optional operation field for remote events. RSE provides the following operations out of the box: /** * Indicates that the event is for a delete operation */ public static final String SYSTEM_REMOTE_OPERATION_DELETE = "DELETE"; //$NON-NLS-1$ /** * Indicates that the event is for a rename operation */ public static final String SYSTEM_REMOTE_OPERATION_RENAME = "RENAME"; //$NON-NLS-1$ /** * Indicates that the event is for a create operation */ public static final String SYSTEM_REMOTE_OPERATION_CREATE = "CREATE"; //$NON-NLS-1$ /** * Indicates that the event is for a move operation */ public static final String SYSTEM_REMOTE_OPERATION_MOVE = "MOVE"; //$NON-NLS-1$ /** * Indicates that the event is for a copy operation */ public static final String SYSTEM_REMOTE_OPERATION_COPY = "COPY"; //$NON-NLS-1$ However, users can define new ones since these are just strings. To describe the old names, prior to a rename, move or copy operation, I've modified the oldName field and getOldName() method for the events to support multiples (since move and copy events often involve more than one src object). As a result of these changes, I needed to update the events as well as the system registry methods that create them. Let me know whether you think this approach is okay.
I can't really see what the "operation" should be good for. The kind of operation should be obvious from the other args. Can you come up with a case where you think the clients definitely need the "operation"? What I'd like to see though is getting an indication about what subsystem the resources came from. It's possible to copy & paste across subsystems, e.g. DStore-files --> Local-files. The "oldAbsoluteNames[]" array just holds the absolute names which do not include that source subsystem as far as I know, right? We do have some mangling code that creates a String to uniquely identify a remote object including its subsystem and absolute path. Perhaps this should be used here.
(In reply to comment #4) > I can't really see what the "operation" should be good for. The kind of > operation should be obvious from the other args. Can you come up with a case > where you think the clients definitely need the "operation"? > What I'd like to see though is getting an indication about what subsystem the > resources came from. It's possible to copy & paste across subsystems, e.g. > DStore-files --> Local-files. The "oldAbsoluteNames[]" array just holds the > absolute names which do not include that source subsystem as far as I know, > right? > We do have some mangling code that creates a String to uniquely identify a > remote object including its subsystem and absolute path. Perhaps this should be > used here. Strange, I thought I replied to this yesterday. Anyway, an example scenario I have is this: User does a move which results in first a DELETE event followed by a CREATE event. A listener that receives the DELETE event needs to know the "operation" in order to tell this is the result of a move as opposed to a delete. Even though the args of the old absolute names are there, that information still could be used in a delete operation so it's not enough just to have those args. As for qualifying the names with the subsystem id, we could do that, as we have for drag and drop, although we need to make sure not the break the previous functionality. Perhaps we could have an additional api that returns the names relative to the subsytem.
I thought that DELETE could have a new "targetPath" argument which would be empty in case of delete but existent in case of a MOVE. Really, I can't find a scenario that requires the operation, an you? You're right of course that adding the subsystem must not break existing clients. But any newly added fields (like targetPath / sourcePath) could be mangled names like it's done for drag&drop.
(In reply to comment #6) > I thought that DELETE could have a new "targetPath" argument which would be > empty in case of delete but existent in case of a MOVE. > Really, I can't find a scenario that requires the operation, an you? > You're right of course that adding the subsystem must not break existing > clients. But any newly added fields (like targetPath / sourcePath) could be > mangled names like it's done for drag&drop. Even if the overall operation can be inferred from the arguments, I would find programmatic usage to be uncomfortable. We'd be asking developers to try to guess what the actual operation is by looking at paths that we store in the event when instead we could be explicit about it.
It looks like you committed the fix with a wrong checkin comment, [223204] [cleanup] fix broken nls strings in files.ui and others
(In reply to comment #8) > It looks like you committed the fix with a wrong checkin comment, > [223204] [cleanup] fix broken nls strings in files.ui and others I accidently committed SystemDNDTransferRunnable with that. I've since taken that back.
Looks like you've committed more with this message: SystemTableTreeView SystemTableViewPart SystemView SystemScratchpadView SystemBaseCopyAction SystemTableView
(In reply to comment #10) > Looks like you've committed more with this message: > SystemTableTreeView > SystemTableViewPart > SystemView > SystemScratchpadView > SystemBaseCopyAction > SystemTableView Yeah, I realized that after. I've committed the rest of the changes now too so it's all in cvs now.
Marking this as fixed since the code was already committed.
