[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] new feature request
|
Hi All,
Attempting to build a shared editor, whether or not synchronous modifications are supported, will really put ECF on the map in my opinion. I think this is quite a critical point in the project.
Scott: one quick question: is the goal of ECF to provide general collaboration support within eclipse, or is it tailored specifically towards software engineering? I'm a little confused because of the focus on chat facilities and the shared graph editor? Has development focused on this because these are fairly easy applications to start with?
Before much development work is done towards shared editors, some of you might be interested in taking a look at SubEtha Edit (
http://www.codingmonkeys.de/subethaedit
). This is one of the most popular multi-user editors, and it is designed primarily for source code editing. By taking a look at the screenshots, it might give the ECF developers a few ideas of what they want to support now, and what might be in the pipeline in later releases.
Incidentally, should my occasional ravings/comments be posted here, or to the newsgroup?
Hope that helps,
~Carl.
On 11/12/05, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Ed,
Ed Burnette wrote:
>Can you share an editor you already have open?
>
>
Not yet, although this would be a logical next feature...along with the
ability to remotely control (to some degree) scrolling, marker
creation/removal, etc. I need to look a little more closely at the
editor extension points that allow listeners (to editor events) to be
set up and menu items/actions added to the context menu.
>Will each user see each others changes, either while they are typing them, or when they save?
>
>
No...not yet anyway. The original request from Ward and Bjorn for this
'shared editor' was simply for a shared editor for simple walkthroughs
and what Ward refers to as 'exploratory testing'.
This doesn't at all invalidate the idea of detecting local changes,
serializing them, sending them, receiving them, deserializing those
changes and applying them to the remote copies...along with having some
mechanism (defined by extension point) to prevent or resolve
synchronization conflicts...but the initial stab at this is intended
simply to support a more modest (but still potentially quite useful) use
case.
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
