Kate and KDevelop sprint in January 2014
From January 18th to 25th, Kate, KDevelop and Skanlite developers met in Barcelona. The sprint was focused on the work of the upcoming few months, and covered a wide range of aspects of these projects.
left to right, back row: Kevin Funk, Gregor Mi, Dominik Haumann, Christoph Cullmann, Milian Wolff, Joseph Wenninger front row: Sven Brauch, Aleix Pol, Heinz Wiesinger, Miquel Sabaté
One of the big initiatives that the developers have been working on recently is the KDE Frameworks 5 migration. During the sprint, Kate's port to Frameworks 5 matured while KDevelop received its first push towards the adoption of the new Frameworks. This is an important step because it lets the team think ahead about adopting the technologies that will be developed on for the next years.
KDevelop
KDevelop also improved on the supported languages front. The new KDevelop Clang plugin got a big push, and, while it is not going to be released yet, it is expected to supersede the current C++ plugin in the long term. Clang is expected to improve the support for standard C++, and also offers an opportunity to support C projects properly. Eventually, an Objective-C plugin could be built on top of Clang. Clang integration reduces the maintenance burden compared to the self-written C++ parser. During the sprint, we carved out a roadmap for the Clang plugin and also extended what we already have so far. The main focus was on polishing infrastructure inside KDevelop for providing a solid base for integrating Clang's useful diagnostics and fixits module.
Clang diagnostic
Currently, the kdev-clang plugin consists of only about 4000 lines of code, compared to nearly 55000 in the old plugin. Further good news—there will be a Google Summer of Code 2014 project that will take care of delivering a first releasable version. There's still a lot to do to make this as usable as the previous C++ support plugin. Read more about kdev-clang.
KDevelop's code assistant popup has gotten a revamp, which will -- after some polishing -- provide a more flexible and better integrated UI for the assistant features. The useful "blame" feature, which shows who touched each line in the current file as provided by the project's VCS, was improved as well. It now shows the commiter's name instead of the commit identifier and also works properly with dark color schemes. KDevelop's interface is now more customizable, toolviews can be detached (for example, source code documentation can be detached from the main window and moved to another screen). KDevelop's codebase was cleaned up and quite a few optimizations were added. This and other improvements will give a noticeable performance boost when operating on large projects consisting of thousands of files.
Find out quickly who the writer is
Python
Much internal cleanup was done in Python support and some long-standing bugs were fixed, such as the debugger not working properly. Python 3 support is now finished, and future development will focus on that.Ruby
The KDevelop Ruby plugin was also greatly improved during the sprint. Lots of bugs have been fixed and a first stable release is closer now.PHP
The sprint also provided a good opportunity to improve the language support within the PHP plugin. A lot of progress was made on completing syntax support for the new features introduced by PHP 5.4. Most notably there is now full support for PHP's trait syntax. While catching up with newer syntax features is important, so too is improving support for older features. One of the most requested improvements for the plugin is proper support for PHP's namespace syntax. During the sprint we worked on making this a lot more usable. However, there are still some kinks to be worked out.Kate
For Kate, the focus was mostly on the Frameworks 5 port. The port already started back in December 2013, resulting in the KF5-ready KTextEditor framework and stable KF5/Qt5 versions of the Kate and KWrite applications. During the sprint, the Kate team worked on a lot of details, polishing the KTextEditor framework.KTextEditor Interface Cleanup
The KTextEditor interfaces are responsible for all the interaction between the editor component Kate Part and the host application (eg. KDevelop, Kile, Kate, ...). So it is important that these interfaces allow good integration of the editor into the host applications. During the sprint, these interfaces were cleaned up and optimized for speed. In addition, the default colors were extended to allow for better color schemas in the future.New Status Bar
Previously, Kate Part did not provide a status bar. All host applications (KDevelop, Kile, ...) had to write their own variant of a status bar, displaying the cursor position and similar information. In the KTextEditor framework, Kate Part will ship a default status bar, showing the cursor position, the edit mode, the modification state, the highlighting, encoding and the indentation settings. Further information can be found in this blogpost.KTextEditor Plugin Architecture
KTextEditor's plugin architecture was improved substantially. Plugins written for the KTextEditor framework will be available in all applications embedding Kate Part, making it possible to share a lot of features such as collaborative editing, search & replace in multiple files, and similar tools. This is possible because the plugin interfaces are now much more powerful than the former interface for shared plugins.As a byproduct, the Kate application interfaces were completely dropped in favor of the KTextEditor plugin architecture. Most of the Kate plugins are already turned into KTextEditor plugins, such as the Documents sidebar, the Filesystem Browser, Search & Replace, the Build Plugin, the Backtrace Browser.