[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Re: Collaborative editing in KTE
From: Kakadu <kakadu.hafanana () gmail ! com>
Date: 2013-04-02 8:45:41
Message-ID: CAGmVoG2bD50DmY2-wXZOx6o_jGmdtP4GuhujoXdv-x3902aqfA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hey
While developing this plugin we tried to test pair programming approach and
creating best plugin for collaborative editing wasn't our aim. We decided
not to to use telepathy related libraries to make our plugin more
standalone and to avoid most dependencies.
AFAIR it sends user editing actions and sometimes synchronize whole
document.
Kind regards,
Kakadu
On Mon, Apr 1, 2013 at 10:14 PM, Dominik Haumann <dhaumann@kde.org> wrote:
> Hi Sven,
>
> this issue/wish comes up every few months.
> And pretty much every time we point out that it's probably not so easy to
> get
> all corner cases right. You'd need to mess with the undo/redo history,
> making
> it accessible via the KTE interfaces. And undo/redo is a core part of kate
> part, it's something that is rather fragile.
>
> I'm not saying it cannot be done, so feel free to hack on it in a kate
> clone.
> We also get GSoC students that want to implement this. But it's far beyond
> the
> scope of gsoc students. It would pretty much certainly fail, or at least
> never
> make it into the Kate code base.
>
> Interestingly, there was a patch some time ago, which implements a
> collaborative editing mode as a KTextEditor plugin:
> https://github.com/Kakadu/Neznaju
> Given that it's just a few lines of code, it works remarkably well. Maybe
> something you want to look into. Still, it doesn't catch all corner cases,
> so
> in its current form, it's not an option.
>
> I can't say much more on the topic, but if you see clean ways to implement
> this, go for it in a personal clone ;)
>
> Greetings,
> Dominik
>
> On Saturday, 30. March 2013 12:00:44 Sven Brauch wrote:
> > Hi kate list,
> >
> > I'm currently making an attempt to integrate collaborative editing
> > into KTE-based apps using libinfinity [1]. There has been a project
> > called kobby [2] which tried to do this before, however it built its
> > own text editor based on katepart, while I'd like to implement it in a
> > more general form (as a KTE plugin). That way, it would be usable in
> > applications like KDevelop and kile as well. I am CCing the developers
> > of kobby and libinfinity with this mail.
> >
> > Kobby is a nice proof-of-concept which shows that collaborative
> > editing can be done with KTE. If possible, I'd like to re-use as much
> > of its code as possible, especially the integration with the document
> > and the connection stuff. If one finds an elegant way to put all this
> > together, the effort to get it working could be fairly reasonable.
> >
> > There's one main problem which needs to be solved, however: How to
> > manage documents? As you surely know, this cannot be done from the KTE
> > plugin itself, since KTE plugins have no concept of opening documents
> > (since they do not know of the embedding application itself).
> >
> > Kobby has a remote browser for browsing documents on the collaborative
> > server, and a local browser for currently open documents. Using that
> > widget would be one way to solve the problem: 1) Write a kate /
> > kdevelop / ... plugin which provides the remote browser view; 2) from
> > that plugin, query the kobby KTE plugin to start managing the document
> > when it is opened. This solution however is far from elegant -- it
> > requires a seperate plugin to provide the toolview(s) for each
> > application the collaborative functionality should be used in, and
> > requires (currently not available) fiddly logic to offer communication
> > between two plugins, of which one is in some random application, and
> > the other is in KTE. The plugin providing the document browser and the
> > kobby plugin would need to pass information between each other, which
> > seems error-prone and difficult to write.
> >
> > Thus I have another idea which I want to hear your opinion about. All
> > apps using KTE I know of have some way to browse a filesystem
> > directory in a toolview (or at least, they have KDEs "open" dialog). I
> > could thus write a simple infinity:// kioslave which communicates with
> > the infinity (collaborative) server and presents the available
> > entities as directories and files (which they are, anyways). Then, the
> > application's native way of browsing directories could be used to open
> > documents from the collaborative server -- all the KTE plugin would
> > have to do is watch for the editor opening a document with an
> > infinity://... URL, and start syncing it if it does. As a free bonus,
> > it would also be possible to browse collaborative servers in e.g.
> > dolphin.
> > The huge advantage this solution would possibly have would be that the
> > whole collaborative stuff could be implemented completely in a KTE
> > plugin, and would thus be available to any application using KTE
> > without changes to the application being necessary.
> >
> > What do you think about this kioslave idea? Could it work? Or would
> > you rather recommend going the way of having seperate application and
> > KTE plugins communicating?
> >
> > Another question -- is there a fundamental problem which would prevent
> > a KTE plugin to take control of the undo/redo actions (i.e. disable
> > them and receive a signal instead or so)? This would also be required
> > in order to implement this properly.
> >
> > Thanks for reading this (far too long) mail and best regards,
> > Sven
> > ________
> > [1] http://gobby.0x539.de/trac/wiki/Infinote/Libinfinity
> > [2] http://kobby.greghaynes.net/
> > _______________________________________________
> > KWrite-Devel mailing list
> > KWrite-Devel@kde.org
> > https://mail.kde.org/mailman/listinfo/kwrite-devel
>
[Attachment #5 (text/html)]
<div dir="ltr"><div><div><div><div>Hey<br><br></div>While developing this plugin we \
tried to test pair programming approach and creating best plugin for collaborative \
editing wasn't our aim. We decided not to to use telepathy related libraries to \
make our plugin more standalone and to avoid most dependencies.<br> <br></div>AFAIR \
it sends user editing actions and sometimes synchronize whole \
document.<br><br></div>Kind regards,<br></div>Kakadu<br><br></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 1, 2013 at 10:14 PM, \
Dominik Haumann <span dir="ltr"><<a href="mailto:dhaumann@kde.org" \
target="_blank">dhaumann@kde.org</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi Sven,<br> <br>
this issue/wish comes up every few months.<br>
And pretty much every time we point out that it's probably not so easy to get<br>
all corner cases right. You'd need to mess with the undo/redo history, making<br>
it accessible via the KTE interfaces. And undo/redo is a core part of kate<br>
part, it's something that is rather fragile.<br>
<br>
I'm not saying it cannot be done, so feel free to hack on it in a kate clone.<br>
We also get GSoC students that want to implement this. But it's far beyond \
the<br> scope of gsoc students. It would pretty much certainly fail, or at least \
never<br> make it into the Kate code base.<br>
<br>
Interestingly, there was a patch some time ago, which implements a<br>
collaborative editing mode as a KTextEditor plugin:<br>
<a href="https://github.com/Kakadu/Neznaju" \
target="_blank">https://github.com/Kakadu/Neznaju</a><br> Given that it's just a \
few lines of code, it works remarkably well. Maybe<br> something you want to look \
into. Still, it doesn't catch all corner cases, so<br> in its current form, \
it's not an option.<br> <br>
I can't say much more on the topic, but if you see clean ways to implement<br>
this, go for it in a personal clone ;)<br>
<br>
Greetings,<br>
Dominik<br>
<br>
On Saturday, 30. March 2013 12:00:44 Sven Brauch wrote:<br>
> Hi kate list,<br>
><br>
> I'm currently making an attempt to integrate collaborative editing<br>
> into KTE-based apps using libinfinity [1]. There has been a project<br>
> called kobby [2] which tried to do this before, however it built its<br>
> own text editor based on katepart, while I'd like to implement it in a<br>
> more general form (as a KTE plugin). That way, it would be usable in<br>
> applications like KDevelop and kile as well. I am CCing the developers<br>
> of kobby and libinfinity with this mail.<br>
><br>
> Kobby is a nice proof-of-concept which shows that collaborative<br>
> editing can be done with KTE. If possible, I'd like to re-use as much<br>
> of its code as possible, especially the integration with the document<br>
> and the connection stuff. If one finds an elegant way to put all this<br>
> together, the effort to get it working could be fairly reasonable.<br>
><br>
> There's one main problem which needs to be solved, however: How to<br>
> manage documents? As you surely know, this cannot be done from the KTE<br>
> plugin itself, since KTE plugins have no concept of opening documents<br>
> (since they do not know of the embedding application itself).<br>
><br>
> Kobby has a remote browser for browsing documents on the collaborative<br>
> server, and a local browser for currently open documents. Using that<br>
> widget would be one way to solve the problem: 1) Write a kate /<br>
> kdevelop / ... plugin which provides the remote browser view; 2) from<br>
> that plugin, query the kobby KTE plugin to start managing the document<br>
> when it is opened. This solution however is far from elegant -- it<br>
> requires a seperate plugin to provide the toolview(s) for each<br>
> application the collaborative functionality should be used in, and<br>
> requires (currently not available) fiddly logic to offer communication<br>
> between two plugins, of which one is in some random application, and<br>
> the other is in KTE. The plugin providing the document browser and the<br>
> kobby plugin would need to pass information between each other, which<br>
> seems error-prone and difficult to write.<br>
><br>
> Thus I have another idea which I want to hear your opinion about. All<br>
> apps using KTE I know of have some way to browse a filesystem<br>
> directory in a toolview (or at least, they have KDEs "open" dialog). \
I<br> > could thus write a simple infinity:// kioslave which communicates with<br>
> the infinity (collaborative) server and presents the available<br>
> entities as directories and files (which they are, anyways). Then, the<br>
> application's native way of browsing directories could be used to open<br>
> documents from the collaborative server -- all the KTE plugin would<br>
> have to do is watch for the editor opening a document with an<br>
> infinity://... URL, and start syncing it if it does. As a free bonus,<br>
> it would also be possible to browse collaborative servers in e.g.<br>
> dolphin.<br>
> The huge advantage this solution would possibly have would be that the<br>
> whole collaborative stuff could be implemented completely in a KTE<br>
> plugin, and would thus be available to any application using KTE<br>
> without changes to the application being necessary.<br>
><br>
> What do you think about this kioslave idea? Could it work? Or would<br>
> you rather recommend going the way of having seperate application and<br>
> KTE plugins communicating?<br>
><br>
> Another question -- is there a fundamental problem which would prevent<br>
> a KTE plugin to take control of the undo/redo actions (i.e. disable<br>
> them and receive a signal instead or so)? This would also be required<br>
> in order to implement this properly.<br>
><br>
> Thanks for reading this (far too long) mail and best regards,<br>
> Sven<br>
> ________<br>
> [1] <a href="http://gobby.0x539.de/trac/wiki/Infinote/Libinfinity" \
target="_blank">http://gobby.0x539.de/trac/wiki/Infinote/Libinfinity</a><br> > [2] \
<a href="http://kobby.greghaynes.net/" \
target="_blank">http://kobby.greghaynes.net/</a><br> > \
_______________________________________________<br> > KWrite-Devel mailing \
list<br> > <a href="mailto:KWrite-Devel@kde.org">KWrite-Devel@kde.org</a><br>
> <a href="https://mail.kde.org/mailman/listinfo/kwrite-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kwrite-devel</a><br> \
</blockquote></div><br></div>
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic