These type of cool articles pop up from time to time on reddit/r/cpp, so if you are interested in C++ topics, this is definitely worth to follow.
This is a follow-up to Aaron’s blog Frameworks 5: Timing is everything, put into the perspective of Kate and the KTextEditor interfaces. In short, Aaron suggests application developers the following:
When Frameworks 5 has a firm release schedule, then it makes sense to start coordinating application releases targets with that and syncing up development cycles.
I agree with this entirely, provided it’s really about applications. In the context of Kate, this is not the case, since the term ‘Kate’ usually also refers to the ‘KTextEditor’ interfaces along with its implementation ‘Kate Part’.
In essence, the KTextEditor interfaces together with Kate Part provide a text editor in a library that can be used by applications, or more to the point, KTextEditor+Kate Part build a framework.
In fact, about a week ago, the KTextEditor interfaces and Kate Part were split out of the kate.git repository. So from now on, kate.git contains the Kate and KWrite applications. The ktexteditor.git module contains the KTextEditor interfaces and Kate Part.
ktexteditor.git is is a tier3 framework and meanwhile officially part of the frameworks initiative: if you want so, KDE now provides 58 frameworks instead of the previously announced 57!
Why timing is everything
Now what about timing? Started on November 28th 2013, Christoph pushed the first compiling version of Kate into the frameworks branch. This was very good timing, since the split of kdelibs into all the frameworks was more or less just finished at that time. Or to put it the other way round: Christoph started porting Kate pretty much as early as the KF5 initialive allowed us – cool!
Around that time by coincidence, Michal started to work on Kate in the master branch and committed lots of cool features. However, since Kate was already rudimentary ported to Qt5 and KF5, the code base diverged more and more, so merging got more complicated. Therefore, Michal started to work in Kate’s frameworks branch. And within only a week (!), Kate, KWrite, the KTextEditor interfaces and Kate Part build without a single warning, meaning that the code was completely free of Qt4 and kde4support – wow!
Again, a month before would have been too early – so this was perfect timing. The result was a pretty stable and mostly bug-free Kate in mid of December.
Well, not completely free of porting bugs. For instance, file saving did not work correctly, ending up in data corruption. It turned out that this was an issue in the framework karchive, which David Faure was able to reproduce and fix. This is good timing in the sense that without Kate’s usage of karchive, the bug would have probably ended up in the technical preview TP1. But it didn’t – yay!
Last but not least, the Kate and KDevelop developers planned already months ago to have a joint Kate/KDevelop sprint from 18th to 26th of January, 2014. Given the current state of Kate and KTextEditor, this again is perfect timing, since most of the KTextEditor cleanup are already done. So the Kate developers can focus on the needs of e.g. KDevelop, on fine-tuning and implementing interfaces, etc. So in about two weeks, when our developer sprint will have ended, Kate will most probably shine as it never did before. And this is the case already now, even before a firm release date of Plasma 2 exists.
This is great news for Kate and all applications that use the KTextEditor interfaces, as Kate/KTextEditor already now reached a maturity that they never had before.
And this is so awesome! I cannot think of better timing Thanks to all who made this happen!
Since the KDE SC 4.12 release a month ago, it’s about time to look at the changes of Kate in 4.12:
- Vi input mode: complete macro support
- Heavily improved vi input mode
- Multi-column text editing (thanks to Andrey Matveyakin)
- MiniMap: align to the top (instead of vertically centered)
- Projects plugin: modified files now show a modified icon
- Improved C++/Boost Style indenter
- in total, 21 issues (including wishes and bugs) were fixed
What comes next?
Kate will get more polishing in the next 4.x releases, for instance, in KDE SC 4.13 Kate optionally supports animated bracket matching.
However, as already mentioned in Kate in 4.11, the main efforts are put into making Kate on Qt5 and Frameworks 5 rock solid. Already now Kate, KWrite and Kate Part are fully ported, i.e. all are free of KDE4support libraries. A preview (already one month old!) can be found here.
Besides that, Kate and KDevelop again join forces and there is a developer meeting from 18th to 25th of January 2014. So expect quite some blogs about Kate on 5 then!
a long time ago, the license of most parts of Kate/KWrite/KatePart/KTextEditor was LGPLv2+ (in the old time, where it was named KWritePart/Kant/…, the original KWrite had that license originally, at least all parts of the component of it).
Then, we changed that to be LGPLv2 (only).
It seems, that was a poor choice, as we now run in v2 vs. v3 vs. any later version problems.
Most parts of the code are easy to relicense, as the contributors either acknowledged the request to change the license to that to the Kate team (on firstname.lastname@example.org) or added themselves to the relicensecheck.pl in kde-dev-scripts.git.
KTextEditor is now LGPLv2+ only, which is nice
KatePart is only missing the re-licensing of some files.
Kate has more files to look at, but should be less a problem, as it has less people that did commits, compared to the part.
So, if you didn’t already get a mail from me about some “please allow on email@example.com for license change to LGPLv2+” and you know you have contributed, even if it was only some patch, it would be really nice to get some short “I am ok with LGPLv2+” on firstname.lastname@example.org.
That will make it much easier to sort out the remaining issues!
This really would help to have no licensing issues coming up in the future years and further incompatibilities. I really would like to strife for LGPLv2+ only code in KTextEditor/KatePart/Kate, at least in the core parts (e.g. without the plugins), which seems to be realistic in the short term to reach.
Thanks a lot and a happy new year.