After three months and 430 commits introducing 23165 changes (line insertions/removals; in the kte-collaborative repository, plus about 50 more commits in kde-telepathy and libqinfinity), the beta release I hereby announce marks the end of my Google Summer of Code project, which consisted of implementing collaborative text editing in KTextEditor (see previous).

For more general information about the project, make sure to also have a look at the user manual, which has some in-depth explanations on how things work.

First, the technical stuff:

Now, read on for the more interesting things!

Initiating sessions from the kde-telepathy chat window

To make the feature more discoverable and intuitive to use, there’s now a “Share document with contact” button in kde-telepathy’s chat window.

You can easily share documents with contacts right from the chat window.

It allows you to select a document, and asks the remote to accept the request. After that, it’ll automatically launch both person’s favourite editor to edit the document; in the case below, you can see a person with kwrite editing a document with someone using KDevelop.

Collaborative editing session initiated by kde-telepathy. There’s a plasma session running for a different user (with his own jabber account) inside a Xephyr window, to simulate two different people using the feature.

This way, you can for example quickly get help from someone regarding a programming problem. It’s much easier than using pastebin or similar services, since both persons can edit the document in real-time, look at it with proper syntax highlighting, etc.

The KWrite user quickly got useful help from his imaginary friend.

Notifier

There now finally is a feature to tell you when new files are added to a server you’re connected to, or on a connection you previously set up with a contact. The same program will automatically refresh all affected folder views, so that you actually notice when new files are added.

The new notification module tells you when new documents were added to a connection. You can of course disable these notifications.

New user list

I re-wrote the user list (not that there was terribly much code to rewrite) to be prettier and more useful; especially, it now includes the colors of the users, and can be configured to show only some users. If the list ends up taking too much space, it will collapse into a minimal form, displaying only colored icons with tooltips.

The new user list, and its configuration options, when there’s enough space.

Collapsed form of the new user list.

“Splash Screen”

Since especially for telepathy-initiated connections, the connection might be a bit slow and for larger documents loading might take several seconds, the program now includes a splash screen to make the user aware of the loading progress. It also serves the purpose of making it clear that although the document is already open and contains text, it may not yet be edited since synchronization is still in progress.

Splash screen displayed while a document is being loaded.

Unicode support

There’s now finally proper support for the full range of unicode characters.

Have fun adding cat faces to your collaborative documents.

User manual

I have written a detailed user manual, which is available as a PDF. The most recent version is always available here.

Mandatory statistics

I already put some statistics in the preamble; but calculating those left me wondering, how much is that actually? Is what I do in 430 commits comparable to what other persons do in 430 commits, or are my commits much smaller or much larger than the average?
Of course, those questions cannot be left unanswered. Thus, I wrote a script to compare the median size of commits of different persons. I think a good measure for average commit size is not the average, but the median size of a commit; this will be much more resistant against artifacts than the mean value, especially big commits such as copying over files from a different repository, adding generated files, …

Looking at most of KTp, kte-collaborative and libqinfinity, I get the following interesting data (all the numbers are “number of lines added or removed”, the average/median numbers are “per commit”; changing a line thus counts as 2; ordered by median):

Gregory Haynes: average 115.1±285.7, median 39.5, total 51 350
Dan Vrátil: average 141.4±401.5, median 19.0, total 22 206
Sven Brauch:  average 54.7±213.6, median 15.5, total 26 353
David Edmundson: average 272.8±7 402.2, median 12.5, total 357 849
Martin Klapetek: average 527.3±11 143.8, median 10.0, total 304 763
Daniele Domenichelli: average 41.4±211.9, median 8.0, total 25 425
Script Kiddy: average 16.3±68.0, median 4.0, total 21 216

(Gregory Haynes is the original author of libqinfinity and kobby, a KDE-based editor using libqinfinity; this project has a different architectural approach, but still I could re-use quite some of the code he created.)

You can clearly see that the mean value is useless, the standard deviation is far too big. The median however looks quite interesting. Deduce from this data whatever you want 😉

Other interesting results turns up when you plot a histogram of “lines changed per commit”; first, me versus Gregory:

Histogram of commit size. Y is ratio of commits with that size, X is commit size in lines.

You can clearly see that I have a significantly higher ratio of commits changing one or two lines (sizes 2 and 4), and generally much more smaller commits, while Gregory has generally more commits in the 25-60 lines added/removed range.

Then, me versus David:

Histogram of commit size. Y is ratio of commits with that size, X is commit size in lines.

The interesting thing to note here is that David has much more commits changing one line (size 2). I boldly claim that commits with small, even numbers are more common if you maintain and improve an existing code base, as opposed to writing new code, since you’ll often fix small issues which are contained in one or two lines (which are changed, and leave you with 2 points per line changed).
If you want to verify or disprove that, feel free to use the program on your own code 😉

• Collaborative text editing in KTextEditor and kde-telepathy: Preview release
• Extracting text from Photoshop (PSD) images

Categories: Everything

Tags: collaborative, planetkde, release

3 replies ›

1. 

   Anonymous

   September 26, 2013 • 08:19

   Hey, thanks a lot for your work, this looks really nice and well thought-out!

   I was wondering, will this also enable us (in some distant future) to do collaborative painting?
   (Not with Krita, but with KolourPaint for some simple sketches.)

   Reply ↓
   • 

     sven

     September 26, 2013 • 11:01

     Thanks!

     I have been thinking about such things and I can roughly explain the situation:

     First of all, KDE's konversation IRC client does have a simple collaborative painting mode, the DCC whiteboard. It sort of works.

     Then, for text all this collaborative stuff is difficult because it needs to be very exact; both people always need to have the exact same text, or things will go wrong. You thus need a complicated algorithm to handle this. For painting on a pixel image though, that's not as critical — you could just implement it the naive way, and the worst thing which could happen is that one person has a line below another line while for the other it's above. Not a big deal. Thus I would say if you just want to write a simple app to sketch some stuff, you're probably better off not reusing this.

     On the other hand, if you want to do it the cool way — which is I'd say by using SVG — things become more interesting. You could most probably re-use the underlying library of this project, called libinfinity, for the operational transform algorithm, but you'd need to wite code on top of that which can merge SVG operations ("add line", …).

     In either case none of *my* work can be re-used for this, since it's purely about integrating the already-existing low-level-library into kate and writing some networking code (the latter you might be able to re-use, in fact).

     So it really depends on what you want. If you want a pure pixel-based painting (no text, no shapes, no layers — just painting pixels) that might be pretty easy to do if you don't need it to 100% accurate in case of conflicts. I'd guess it's a project you could do in e.g. kolourpaint in a week or less.

     Cheers,
     Sven

     Reply ↓
2. 

   sven

   September 27, 2013 • 11:01

   [Re-posting comment which was eaten by the spam filter]

   Anonymous wrote:
   Ok, thanks for clarification. Definitely not looking for svg. Didn't know there is such feature in konversation. However I'm looking for such thing in telepathy.
   So your libary cannot be used, but you also did some gui stuff ("share documents", notifier, etc.), I think this could be reused if someone wants to share painting.

   Reply ↓