Community
Participate
Working Groups
I tried Real-Time Shared Editing over XMPP with two GTalk accounts and it works very well. Great work. :) One aspect that I think could be improved is the case where both users have the same project checked out and want to do shared editing over one or more files from it. In this case, it would be nice if ECF recognized this and allowed the receiver of the request to have the same functionality as the originator (e.g. auto-complete, incremental compiling with error-reporting, etc.)
(In reply to comment #0) > In this case, it would be nice if ECF recognized this and allowed the > receiver of the request to have the same functionality as the originator (e.g. > auto-complete, incremental compiling with error-reporting, etc.) If they have the same projects, wouldn't the plug-in technically be at work on both ends? Or do you mean if one person has JDT and the other doesn't?
I don't know what's supposed to happen. :) What does happen is that the person who receives the request doesn't enjoy any of the usual JDT functionality for files that are inside projects (as already said, e.g. content assist, incremental compilation with error-reporting, etc.). Instead you get an editor with syntax highlighting and little else. Note that the person who _sends_ the request enjoys full functionality.
(In reply to comment #1) > (In reply to comment #0) > > In this case, it would be nice if ECF recognized this and allowed the > > receiver of the request to have the same functionality as the originator (e.g. > > auto-complete, incremental compiling with error-reporting, etc.) > > If they have the same projects, wouldn't the plug-in technically be at work on > both ends? Or do you mean if one person has JDT and the other doesn't? > The docshare plugin (and rest of ECF) is at work on both ends. I suspect that what is meant by the original request is that for the receiver of the shared editing, the shared file/resource is correlated with the file of the same project/name in the workspace...which the docshare plugin currently does not do. Is that right ijuma? Although doable, the requested enhancement is not trivial...precisely because the file/resource...even with same name in both workspaces...may not have the same content upon shared editing start (i.e. both copies may have local changes). And if not the same, it's not at all clear how the receiver should proceed (as synchronizing them is complicated, and writing over the local resource with the shared editor content can easily be badly destructive). In any event, there are some subtle issues to think through here about dealing with all possible cases for resources that are actually shared in the initiator/receiver workspaces. I'm looking forward to working through some of these issues as ECF moves to 2.1 and beyond. BTW, in the collab example, we support the use case of remotely opening, selecting, and navigating through resources...but no changing. In the UI this is represented by an item on the context menu item "Share Resource to Collaboration"...if the user is actually connected to a collaboration group.
Yes, Scott, that's precisely what I would like to see. I understand that it's not easy, but it would certainly be nice. Personally, I would be very happy if it dealt with the 2 most common cases from my experience: (1) 2 users are pair programming so the files are identical when the sharing starts. (2) User 1 started making some changes, but ran into some issues and needs help from User 2. Instead of committing something that doesn't yet work or creating a patch, User 1 can simply share the editor with User 2 and they can work together towards a solution. Both of these cases can be accomplished without any merging, although it would be important to warn the user if any destructive changes were going to be performed. The level of integration could be taken to another level if it was possible to hook into the VCS because it would then be possible to know if the files were indeed the same and if there were any local changes from the VCS copy. This could come later of course.
(In reply to comment #4) > Yes, Scott, that's precisely what I would like to see. Great. > > I understand that it's not easy, but it would certainly be nice. Personally, I > would be very happy if it dealt with the 2 most common cases from my > experience: > > (1) 2 users are pair programming so the files are identical when the sharing > starts. > > (2) User 1 started making some changes, but ran into some issues and needs help > from User 2. Instead of committing something that doesn't yet work or creating > a patch, User 1 can simply share the editor with User 2 and they can work > together towards a solution. > > Both of these cases can be accomplished without any merging, although it would > be important to warn the user if any destructive changes were going to be > performed. Yes, agreed. > > The level of integration could be taken to another level if it was possible to > hook into the VCS because it would then be possible to know if the files were > indeed the same and if there were any local changes from the VCS copy. This > could come later of course. Actually, hooking into the VCS is very doable...and IMHO a very effective/useful way to go. It also allows addressing other use cases very effectively (e.g. those that do require merge).
(In reply to comment #5) > Actually, hooking into the VCS is very doable...and IMHO a very > effective/useful way to go. It also allows addressing other use cases very > effectively (e.g. those that do require merge). Excellent. :)
how to vote for this bug ?
(In reply to comment #7) > how to vote for this bug ? > You just did! (by adding yourself to cc) :) Thanks. If there are any resources to collaborate with us on completing this work (i.e. helping) please make that known on this bug.
(In reply to comment #7) > how to vote for this bug ? I cannot see an option to vote on this bug either so I suspect it might be a switch. Scott, do you see in anything in the bugzilla admin panel as project lead for the ECF "product"?
Scott, for Ismael's two simple use cases, I suggest we do the following: 1. Modify the information that's being sent to the remote user to contain the IPath's information if it's a workspace resource. If not, we won't use a path (or we can, depending on what the community says ;)). 2. Modify the receiving end to digest the IPath information and check if the same IResource that we retrieve returns true on exists(). If yes, we prompt a dialog for opening compare editor / replace local with incoming version / whatever. We can hook to the SCM system and such, but that can always come later. ;) If exists() is false, we could also be smart and see if the project is closed, if yes, we could prompt to open / whatever / blah blah blah.
Created attachment 119065 [details] Reuse same IFile patch v1 This patch does the following: -alters the retrieved string from the file to be its workspace-relative path to be serialized and sent -if the remote user's file does not exist, reuse the same code as before (creating a DocShareEditorInput) -if the remote file exists, prompt the user that it'll be overwritten, canceling the action will send a StopMessage back to the sharer -accepting the change will search for an editor in the current workbench window and reuse it, if not, open one -retrieve the text editor's IDocument and replace its contents, by replacing the content directly, a user could theoretically just click Ctrl+Z immediately to undo the swap (this would of course be destructive since the sharer would also have all the content reverted, but anyway...)
Created attachment 119067 [details] Reuse same IFile patch v2 org.eclipse.core.resources need to be specified as a dependency.
Created attachment 119078 [details] Reuse same IFile patch v3 This patch will create a backup of the current copy of the file. This is the copy that the resources plug-in currently knows about at the disk-level. If the file is currently open and it is dirty in the editor, the changes there are not taken into account. As the opened editor is reused and the document's text is replaced and can be undone as noted per comment 11, I don't see this as being a big problem.
Resolving as wontfix due to resources. If committer or contributor resources become available for additional work in this area, then please reopen.
