[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] new feature request

Hi Folks,

I've created and checked in an initial stab at the ability to remotely launch an editor. There is more to do here (e.g. add the ability to remotely add/navigate to markers, etc), but it now works like the following:

Assume: A shared project (e.g. CVS) exists in the workspace of each collaboration participant (e.g. org.eclipse.ecf).

Before opening a shared editor, the user must connect a given project (soon the entire workspace) to a collaboration group. This is done by:

1)  Right clicking on the project (e.g. org.eclipse.ecf).
2)  Choosing ECF->Join ECF Collaboration...
3)  Joining appropriate group (e.g.  ecftcp://ecf1.osuosl.org:3282/server)

The ECF Collaboration view (with user list and simple chat) should appear.

Once connected, users can navigate using the Navigator or the Package Explorer into the org.eclipse.ecf resources (i.e. java files, txt, files, .xml files, etc). Then they can open a shared editor on a given resource:

1) Right click on the resource (e.g. IContainer.java in org.eclipse.ecf.core package)
2) Choose ECF->Open Shared Editor


This will open the selected resource with a local editor of the appropriate type...AND it will also send a message to remotes (in given collaboration group), and they will all also open the editor on that resource as well.

I'm thinking of adding the following as well:

1) Something that prompts the receiver of the 'open resource' message to make sure they are 'OK' with opening the given resource in the editor
2) Moving the ECF->Open Shared Editor menu action to the 'Open With' menu at the top (just need to track down appropriate menu ids)
3) Ability to remote add/remove markers of different types
4) Ability to remotely control/navigate to markers from 3


Scott

Carl Cook wrote:

Hi Boris and Scott,
>>If you have any questions about editors etc., feel free to send them my way.
> OK, thanks. One question: Do you think that using markers (where we
> introduce the notion of a marker that is added by a remote user) would
> work? Or should we just pass around selection offset and range for the
> time being and scroll/set selection for the time being?
From painful experience in writing groupware widgets, markers are the only way to go! Using selection offsets gets into all sorts of problems in real-time file sharing, especially when the order of actions between collaborating users can not be predicted in advance. There is nothing worse than sending an offset for a modification only to have someone at the same time change the text above the current cursor position.
I have quite a fair bit of experience in writing such widgets (including the MVC side of things), so if I can help at all with the high-level design, please just post back some questions!
Thanks,
~Carl.


------------------------------------------------------------------------

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev