“Releasemode: On” for Okteta

Release often and early. But not too early, first impression stays. Besides the fact, that holding your code in a public repository is like releasing all the time, I feel now is the time where the mentioned two rules are getting well balanced for Okteta.

So I have set myself in release mode, removing and hiding all undone things, even if they look interesting and like some fun, and setting up a list of those things which need at least to be done for a good first release. There a quite a few, especially after looking at the requirements to move to kdereview. And that is target No. 2. Two targets, that might be one too much. But a release is simply a subtarget of moving to kdereview, so there shouldn’t be any conflicts, I think.

One thing to be done is making the licensing of Okteta complying to KDE’s licensing policy. Okteta was a GPL v2-only project until now. Trying to grasp the idea of GPL v3 I think I am comfortable with that license, too. So I am relicensing all code also to the version 3. But which one to use for KAboutData, it supports only the mentioning of one license? Oh well, there is the source code, here is my editor, this is the free hour.,. so a patch for support of multiple licenses is pending for review in the mailinglist kde-core-devel, please have a look.

But there is another problem with the “About…” dialog. It only mentions the top level program. What about all the libraries and frameworks used by it, which only make the program possible? In the case of Okteta, the code of the program itself are just a few lines, that wire things together. Instead all real functionality is delivered by libkakao, libokteta*, libkde*, libqt*, …, down to libc. Where do all those software modules and their creators get the credit?

Anyway, for now at least the new program-centric multiple-licenses-capable About-dialog for Okteta, like it is possible with the mentioned patch:

(Copyright since 2006? Yes, the first code fragments date back to that year. It was just this winter where I pushed things a little)

Okteta turned into Construction site for Undo/Redo

Almost done, almost done, just the missing final 5 %. Which are quite tough. And never decreasing, one thing done opens a new one, hey.

But still what has been done meanwhile is quite pleasing: After many years wanting to do it I finally simply started and tried a first primitive implementation of the data struture concept called “piece table” as the backend for the undo/redo mechanism of the bytearray model. Piece tables are also used by Abiword and QTextDocument. If you are interested for a start read e.g. the page Part 17 – Editing Text with Piece Chains by some James Brown, so I can omit any experiments in describing it myself.

The code is now with Okteta in KDE’s repository. It is pretty rough and has flaws. Like the cursor forgetting where it has been at the previous changes. That is one of the tough problems, because with multiple views there are multiple cursors, the bytearray document does not know about views, views can come and go, so who is in charge to care for the cursor positions and/or how to calculate them?

And dependencies. I tried to make the piecetable code unaware of the basic data structure (byte array for me), worked so far. Because others might want to make use of the code, too (interested? contact me). But now I see that there are data structures which travel more than one module boundary, like the list of changes (e.g. on multiple undo), which is emitted by the piecetable via the bytearay model to the bytearray view, so the later can do the cursor jumping calculations. Repacking lists is not what I like. And encapsulating by wrapping iterators looks like too much work. Sigh

But other than that, things are looking good. There are already two controllers for undo/redo (or versioning), one classical, which embeds into menu and toolbar, and a (readonly) monitor, which sits in the sidebar and shows all versions. Both operate on the Versionable interface of the libkakao framework, so other document classes implementing this interface can share them (one day when libkakao is ready). The KByteArrayDocument class at least does now, and wraps things to the experimental KPieceTableByteArrayModel. That one still loads files completely in working memory. But once everything works the loading will be switched to memory mapping, so working with GB-sized files should be possible

For now: Stay away from editing with Okteta, it is broken again. Parents are in care for their children.

Standard screenshot following, presenting the latest achievements as described:

Update: Nick’s question made me dig a little. And I found it was almost exactly 4 years ago that I decided to try the piecetable approach, see this thread on the mailinglist koffice-devel. But it stayed on my TODO list until a week ago. Oh, and the PDF document of the paper by Charles Crowley in now available directly at his homepage, too.