Language Selection

English French German Italian Portuguese Spanish

Kde Planet

Syndicate content
Planet KDE -
Updated: 10 hours 48 min ago

Akademy was a blast!

Friday 13th of September 2019 12:00:00 AM

I attended my first ever Akademy! The event was held at the University of Milano-Bicocca in Milan, Italy this year. And the experience was splendid. During the 2 day conference, I had the opportunity to talk at the Student Showcase, where all of the SoC students presented their work to the community. There were about 8 students, and everyone gave a good briefing on their project.

My project this summer was with Kdenlive, the open source non linear professional video editor. I proposed to revamp one of the frequently used tools in the editor, called the Titler tool, which is used to create title clips. Title clips are video clips that contain text and/or images that are composited or appended to your video (eg: subtitles). The problem with the titler tool as it is, is that it uses QGraphicsView to describe a title clip and QGraphicsView was deprecated since the release of Qt5. This obviously leads to problems - upstream bugs crawling affecting the functionality of the tool and an overall degradation in the ease of maintenance of the codebase. Moreover, adding new features to the existing code base was no easy task and therefore, a complete revamp was something in sights of the developer community in Kdenlive for a long time now. I proposed to rework on the backend for the period of GSoC replacing the use of XML with QML and use a new rendering backend with QQuickRenderControl, along with a new MLT module to handle the QML frames. I was able to cover most of the proposed work, I seek to continue working on it and finish evolving the titler tool.

The folks from Kdenlive have always been very warm and helpful especially with the whole learning curve (which definitely was steep) and working with the community so far has been great, I’ve learned a lot from the experienced developers in Kdenlive and from the Kdenlive community. I seek to continue working with the Kdenlive team and KDE to continue making Kdenlive a great tool to use and a great community to be a part of.

All in all, Akademy was an unforgettable experience, I met a lot of brilliant people from the KDE community in person and the other SoC students from other parts of the world. I’m extremely thankful to the KDE community for presenting us, students, with such a fine opportunity and a platform to work and talk on our projects. Kudos to the Akademy Team for orchestrating such an event!

Here’s my GSoC Work Report:

Kate in the Windows Store

Thursday 12th of September 2019 04:25:00 PM

Our Windows Store submission succeeded, we are now officially in the store.

Try out how the Kate text editor performs on Windows for your personal workflow.

If you see issues and want to help out, contributions are welcome on our GitLab instance.

Our Windows team is small, any help is very welcome! Thanks again to all the people that made it possible to use Kate nicely on Windows.

Kubuntu Meets at Milan Akademy 2019

Thursday 12th of September 2019 03:42:37 PM

A few Kubuntu Members (and Councillors!) met Thursday before KDE Akademy’s end. We discussed the coming release (will be 19.10) and the upcoming LTS (20.10) – which will be Plasma LTS *and* Qt LTS. This combination will make this LTS super-supported and stable.

We also discussed snaps and when Ubuntu possibly moves to “all snaps all the time” for applications at least. This may be in our future, so it is worth thinking and discussing.

Tobias Fischbach came by the BOF and told us about Limux which is based on Kubuntu. This has been the official computer distribution of Munich for the past few years. Now however, unless the Mayor changes (or changes his mind) the city is moving to Windows again, which will be unfortunate for the City.

Slightly off-topic but relevent is that KDE neon will be moving to 20.04 base soon after release, but they will not stay on the Plasma LTS or Qt LTS. So users who want the very latest in KDE Plasma and applications will continue to have the option of using Neon, while our users, who expect more testing and stability can choose between the LTS for the ultimate in stability and our interim releases for newer Plasma and applications.

Of course we continue to ask for those of our users who want to help the Kubuntu project to volunteer, especially to test. We’ll soon need testers for the upcoming Eoan, which will become 19.10. Drop into the development IRC channel: #kubuntu-devel on freenode, or subscribe to the Kubuntu Development list:

Kate got submitted to the Windows Store

Thursday 12th of September 2019 12:25:00 PM

Since a few years Kate is working well on Windows. You can grab fresh installers since then from our download page.

But the visibility of it was very low for Windows users.

Already last year the plan was made to increase the visibility of KDE applications by getting them into the official Windows Store.

Like always, Akademy is a great chance to get the last bits ironed out and the stuff done!

Now, thanks to the help of Hannah von Reth and others, we finally got Kate submitted to the Windows Store!

The submission still needs to be processed by Microsoft, stay tuned when our nifty editor will really be available there for download!

Thanks to all people that contributed to this!

Qt 5.12.5 Released

Wednesday 11th of September 2019 11:42:54 AM

I am happy to Announce we have released Qt 5.12.5 today.

News from KDE PIM in July/August 2019

Wednesday 11th of September 2019 09:57:58 AM
KDE Project:

Following Volker's last blog on this topic, here are some highlights of the recent work that has been done around Kontact / PIM during this summer. First of all, stats: there were around 1200 commits in the past two months, leading to the new 19.08 release.

KDE Itinerary

You can have a good overview of Volker's work by following this blog.


It seems our team was mostly focused on cleaning, fixing and introducing little UI features during summer:

Laurent added folder specific exportation from PIM within its PIM data exporter, contact selection from LDAP servers, refactoring some PIM libraries to new ECM macros and cleaned up deprecated method preparing for a Qt 6 future.
In addition to that some bug fixes got in, most notably adding reminders to new events in KOrganizer, text-to-speech fixes and general KMail behavior corrections.

Reminders to new events in Korganizer:

Choosing a contact from LDAP server :

All of the libraries have been adapted to compile with Qt 5.13 and soonish we should reach 5.14 compilation state.

Volker spent time unifying instant message address storage in vCards to KContacts, KContacts soon to be its own framework. The visual style for inline messages in KMail's message viewer was updated too, following the Breeze style as you can see in the picture.

Visuals for inline message boxes in the mail view :

Sandro Knauß worked on the begining of an implementation for MemoryHole support : the idea is to encrypt the mail header (containing metadata) to enforce even further user privacy. In order to achieve that, they wrote a new interface between MimeTreeParser and MessageViewer so we now can update mail headers for later extraction, stay tune for more deails about that next blog posts. In addition and with the help of Glen Ditchfield they put their effort on making messagelib tests green again!

David Faure ported the all of KDE PIM to D-Bus activation as a way to start applications, which enabled the deprecation of KDBusServiceTrader and maybe in a long term future a refactor to simplify KLauncher.


Dan worked on a better support of PostgreSQL (better handling of table name case sensitivity and the sorting of versioned directories). Akonadi server received some love with a few cleanup and modernization treats, you will have more detail about what Dan cooked in his kitchen in his blog so stay tuned!


Volker and Laurent made sure all KDE PIM modules would appear correctly under the, to make the KDE PIM codebase easier to follow and discover.

Help us make Kontact even better!

All these efforts to provide good free software to the world would not be possible without our committers, if you want to take part on that feel free to contact us #kontact and #akonadi IRC channels on Freenode, see the below section to get started:

And again, if you are attending Akademy, feel free to come see us !

This is a guest post from Franck Arrecot due to technical issues with his blog.
Thanks Franck for writing up the above!

KStars v3.3.6 is released

Wednesday 11th of September 2019 06:40:33 AM
The KStars team is glad to announce the release for KStars v3.3.6 for Windows, MacOS, and Linux.

This release is packed with many small quality of life improvements and bug fixes.

Intuitive Popup MenuWe cleaned up the popup menu so that mount actions are more intuitive. Took this chance as well to add some lovely Breeze icons to the mix.

We will continue to make mount controls even more accessible, especially to users over VNC.Live Debayering
The KStars Live Video window can now debayer frames in real-time, thereby allowing for color video streams.

FITS Viewer
A few improvements landed in FITS Viewer:

  • Updated Statistics display that can display value for each color channel separately, if present.
  • Faster loading times thanks to a performance patch by Hy Murveit. Config and Indexes
Robert Lancaster made huge improvements to the handling of configuration management and indexes. This should make these features a lot more accessible to a wider pool of users.

You can edit the configuration file directly in KStars. Furthermore, you can easily add/remove folders that that contain the index files. Many users have the indexes files stored in external hard drivers, and with this feature, it is now very easy to add the additional folders so they get utilized by the solver.

This change is accompanied by changes to the index downloader. Now you can check all your collections, and you have the ability to download indexes to a particular folder in your collection. A green index file indicates that the file is available in the system and does not require to be downloaded.Observatory Weather Info
Wolfgang Reissenberger continued his outstanding work in improving the Observatory Module. With this release comes weather data directly displayed in the module. Along with the configurable thresholds for Warning and Alert states, you can rest easily knowing that KStars can take the appropriate actions to protect your observatory from adverse weather conditions.

Meridian Flip
A small quality-of-life improvement to the Meridian Flip value. You can now toggle between Degrees (default) and hours. Many mounts indicate the meridian flip limit in degrees so we opted to make this as default.

Mount Control Motion Reverse
You can now reverse the direction of each axis of motion separately, in case you prefer to controls to behave in the way you expect them to in the Mount Control Panel.
Setting Coordinates Manually
The dialog now opens pre-populated with the currently selected object coordinates. You can easily switch between JNow, J2000, or your own custom Epoch.

Under The Hood
Yuri Chornoivan is the unsung hero of internationalization efforts in KStars. Many volunteers work in KDE internationalization effort and Mr. Chornoivan keeps a vigilant eye on KStars to make sure it remains accessible to the widest audience possibly globally.

Mr. Chornoivan replaced many obsolete functions in KStars with their up-to-date alternatives.

OpenForum Academy Workshop - Exploring Modern Dimensions of Openness

Tuesday 10th of September 2019 06:00:00 PM

The OpenForum Academy held its second 2019 workshop in Brussels this week. OpenForum Academy is a European-based independent think tank which explains the merits of openness in computing to policy makers, industry and communities across Europe. This workshop series aims at being a forum for practitioners, academics and policy makers to collaborate on various topics of openness and freedom. It is organized by OpenForum Europe, enabling it to bridge between the abstract academic world and policy discussions at the European Commissions. We set out to explore focus topics to answer current challenges to openness that the academy will develop insights and recommendations for. These topics will shape the work of OpenForum Academy for the near future.

Krita 4.2.6 released

Tuesday 10th of September 2019 10:55:39 AM

A bit later than expected, because of a regression found during beta testing, we’re releasing Krita 4.2.6. Over 120 people have participated in the beta test survey, so this is something we’ll repeat for the next release.

This release also contains an important workaround for users with an AMD Ryzen 5 3500 CPU. This CPU has a bug in its hardware random generator that caused crashes.

New features:
  • Add new layer from visible to layer right-click context menu.
  • When running Krita for the first time on Windows, Angle is now the default renderer. Note that if you have an NVidia GPU and Krita’s window is transparent, you need to select Angle manually in Krita’s settings; if you have another GPU and you have problems with the canvas not updating, you might need to manually select OpenGL in the same window.

We want to especially thank Karl Ove Hufthammer for his extensive work on polishing the translatable string.

Bugs fixed
  • Allow selection overlay to be reset to default. (BUG:410470)
  • Set date for bundle creation to use ISO-Date. (BUG:410490)
  • Fix freeze with 32bit float tiff by using our own tiff reader for the thumbnails. (BUG:408731)
  • Ensure filter mask button is disabled appropriately depending on whether the filter supports it. (BUG:410374)
  • Enable the small color selector if opengles is available as well (BUG:410602)
  • Fix mixed Zoom, Pan, Rotate on macOS (BUG:410698)
  • Ensure that checkboxes are shown in menus even when using the fusion theme
  • Isolate Layer Crash (BUG:408785)
  • Properly fix font resetting when all the text in the editor removed (BUG:409243)
  • Fix lags in Move Tool when using tablet device (BUG:410838)
  • Fix Shift and Alt modifiers in Outline Selection Tool (BUG:410532)
  • Ensure Convert group to Animated Layer shows text in the toolbar. (BUG:410500)
  • Allow ‘Add Clone Layer’ to Work on Multiple Layers (BUG:373338)
  • Fix saving animated transparency masks created through conversion (BUG:409895)
  • Partially fix the curve change despite ‘Share curve across all settings’ checked (BUG:383909)
  • Try harder to make sure that the swap location is writable
  • Properly handle timezones in bundles
  • Make sure all the settings dialogs pages are always shown in the same order
  • Make the settings dialog fit in low-res screens (BUG:410793)
  • Remove misleading ‘px’ suffix for ‘move amount’ shortcut setting
  • Make string for reasons for image export problems translatable (BUG:406973)
  • Fix crash when creating a bezier curve (BUG:410572)
  • Fix deadlocks in KoShapeManager (BUG:410909, BUG:410572)
  • Fix a deadlock when using broken Wacom drivers on Linux (BUG:410797)
  • Fix absolute brush rotation on rotated canvas (BUG:292726)
  • Fix deadlock when removing reference image (BUG:411212)
  • Fix a deadlock in handling of vector objects (BUG:411365)
  • Fix autosave saving only once (BUG:411631)
Download Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.


(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)


Note: the gmic-qt is not available on OSX.

Source code md5sum

For all downloads:


The Linux appimage and the source .tar.gz and .tar.xz tarballs are signed. You can retrieve the public key over https here: 0x58b9596c722ea3bd.asc. The signatures are here (filenames ending in .sig).

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

KIOFuse – Final Report

Tuesday 10th of September 2019 10:23:50 AM

The GSoC coding period is now over and it is only appropriate that it is discussed what has been achieved and what needs to be done to see KIOFuse officially included in as a KDE project, allowing the 75324 bug report to be finally closed after a whole 15 years! Before I continue, I’d like to thank my mentors, Fabian Vogt (fvogt) and Chinmoy Ranjan Pradhan (chinmoyr) for all their support and advice during the course of GSoC. I’d also like to thank various reviewers of upstream code who quickly reviewed and merged code that I submitted. My previous posts (here and here) have discussed the work accomplished in May/June in detail.

Currently the way KIOFuse works is that I/O is implemented on top of a file-based cache, in particular, on temporary files. Reading and writing occurs on the temp file. Flushing works by calling KIO::put, which sends the data in our cache to the remote side via a TransferJob. However, whilst this is happening, there’s nothing stopping write requests coming in for that same node, which marks the cache as dirty. Once the job is done, we check if the node is dirty. If it is, we start another TransferJob, as it would be incorrect to say that the node is flushed. If this scenario keeps occurring, we’d never reply with a successful flush. A simple solution, which doesn’t guarantee that this scenario doesn’t occur but can decrease its likelihood, is as follows: every time a chunk of data is requested by the TransferJob we check if the node is dirty. If so, if it is less than 85% complete, restart the job, otherwise let it finish. The patch for this can be found here.

Another task was to refresh the attributes of nodes after a while. Currently, the existence of nodes is only checked lazily, i.e. if lookup or readdir are called. For each new node found (or created) the stat struct (the node’s attributes) is filled with the values from KIO::UDSEntry. However, this is only done once and any changes on the remote side are not noticed. One could always refresh the attributes on every lookup but that may be overzealous, and so the solution chosen was to do a KIO::listDirin readdir if it hasn’t been called on that node in the last 30 seconds. The patch for this can be found here.

Another problem that KIOFuse had was that write permission wasn’t checked, we’d just forward the permission bits received from the remote side and if we in fact couldn’t write we’d only know during flush, which is a bit too late. Although we cannot fully guarantee write access, there are steps taken to try and get as close as possible to a guarantee. First we start a KIO::chown job, which changes the owner to ourself. If we can, then we assume that the owner permission bits are valid, and forward them. If KIO::chown isn’t supported we just allow write requests to go through, as there is simply no way we can actually check. If the job fails (i.e. we’re not the owner of the file), then changing the modification time can actually help us; it doesn’t help us if we’re the owner as we can change the modification time independent of our write permission. If we can change it, then we can write, if KIO::setModificationTime isn’t supported, we just allow write requests to go through. The patch for this can be found here.

As mentioned previously, file I/O is implemented on top of a file-based cache. Data on the remote side is transferred via the help of KIO::get and KIO::put. Some slaves support KIO::open, in particular sftp/smb/file, which means that it is possible to engage in seek-based file I/O. This means that we do not need to use a file-based cache for those slaves, and can simply read and write directly from and to the remote side. This obviously introduces a bit more latency, but also means that we can easily handle large files, such as videos. The biggest issue with getting this implemented is that the documentation on the how to implement KIO::open correctly and its assorted functions consists of one-liners. This means that each slave author has their own idea of what it means to read/write/seek. The solution to this was to study what all three slaves did, and converge on one definition of what we mean by the different functions provided by the FileJob interface. In addition several bugs were squashed. The most surprising of which was the close signal never being emitted; a big sign that no one has used this API properly since its inception in 2006! Issues in the smb/sftp slaves and the mtp slaves were also fixed. The above mentioned patches have all been merged meaning that KIOFuse now requires KF5 Frameworks 5.62 (and kio-extras 19.08.1). The patch that allows KIOFuse to take advantage of KIO::open can be found here.

The main benefit of KIOFuse is obviously integration into KIO itself. The idea is to create a KIOFuse KDED module loaded at startup, which starts the kio-fuse process. On the KIO side, every time we wish to send a KIO URL to an app that we identify as not supporting the given URL, a DBus request is sent to our KDED module, which mounts the URL and sends back the local path of the URL. We then pass it to the application. The beauty of this is that the conversion is transparent and requires no setup from the user; it also induces no slowdown to KIO-enabled applications. In fact, many people won’t even be able to tell that they’re using KIOFuse, non-KDE apps will seamlessly access the KIOFuse path instead of KIO URLs they don’t understand. The patch for the KDED module can be found here, and the patch in KIO that uses that KDED module can be found here.

So, what’s required for KIOFuse to be production ready? Firstly, some of the linked MRs have not been merged, which just requires a bit of time to get it reviewed and in. Secondly, there are still some bugs that need resolving. GDrive files which don’t have a size (usually GDoc files) get corrupted on read (and potentially write), this issue has been looked at but I’ve not yet found a resolution. MTP doesn’t seem to work at all for some reason. Whether this is an issue in the MTP slave or KIOFuse has not been determined, which is making it harder to resolve this issue. Another thorny issue is that conversion from a local path to a remote URL is a bit buggy. This should be resolvable, but it needs to time to get it right. Ideally, we’d like more testing on all slaves. One potential cool way of testing KIOFuse is using fio, which performs several intensive tests, usually for kernel file systems; this is something we definitely should explore. There is also the question of how KIOFuse will be included in KDE, for example, will it be a framework?

Note that I’m at Akademy, so feel free to ask any questions about it either there or on this blog.

More control over warnings for and visibility of deprecated library API via generated export macro header

Monday 9th of September 2019 05:10:30 PM

Or: More preparation for the autumn of version 5 of KDE Frameworks

Consumer and producer interest in legacy in a library API

During the development life-time of a library in a API-compatible major version, quite some part of its API can be found to be insufficient and thus be deprecated in favour of API additions that serve the purpose better. And the producers of the library want to make the consumers of the library aware about those changes, both to make the investment into the improved API pay out for the consumers as well as prepare them for the future removal of the old API. As a deprecation note in the API documentation or release notes might be missed for existing consumer software, the compiler is pulled into the game using deprecation attributes on the API symbols, so developers looking at the build log have a chance to automatically be pointed to use of deprecated API in their software.
Next, once the chance for dropping the legacy parts of an API arrives on a change to a new major version, again having the compiler support pointing out that part is easier then grepping over the codebase for potentially pattern-less informal notes in code comments or the documentation.

At the same time consumers of a library might be well aware about API deprecations. But they might want to support a range of released versions of the library, using a single code base without variants for the different library versions. They might have more important issues to solve than deprecated API and want to get rid of any deprecation warnings at all. Or they want to ensure that no new uses of deprecated API is added.
Others consumers again might want to use custom builds of the library with all the implementation for deprecated API dropped, at least until a certain version, to save size when bundling the library product.

KDE Frameworks: … TODO

KDE Frameworks, the continuation of the “kdelibs” bundle of libraries, but with emphasis on modularization, is now at API-compatible major version 5. Yet one can find legacy API already deprecated in version 3 times, but done so only as comment in the API dox, without support by the compiler. And while lots of API is also properly marked as deprecated to the compiler, the consumer has no KDE Frameworks specific option to control the warnings and visibility. While some “*_NO_DEPRECATED” macros are used, they are not consistently used and usually only for deprecations done at version 5.0.

As you surely are aware, currently the foundations of the next generation of Qt, version 6, are sketched, and with the end of 2020 there even exists a rough date planned for its initial release. Given the API breakage then happening the same can also be expected for the libraries part of KDE Frameworks. And which would be a good time to also get rid of any legacy cruft.

New: ECMGenerateExportHeader, enabling more control about deprecated API

A proposed new addition to KDE’s Extra CMake Modules (ECM) should allow to improve the situation with KDE Frameworks, but also other libraries: ECMGenerateExportHeader (review request).

It would generate an extended export macro definition header which also includes macros to control which parts of the deprecated are warned about, are visible to the compiler for library consumers or included in the build of the library at all. The macros would be inspired by similar macros introduced with Qt 5.13, so the mind model can be transferred.
(Inspired, but not a plain copy, as e.g. the name “QT_DISABLE_DEPRECATED_BEFORE” is a bit misleading, as the macro is specified to work as “before and including”, so the proposed inspired name uses “*_DISABLE_DEPRECATED_BEFORE_AND_AT”.)

More elaborated example usage would be like this (note the difference between FOO_BUILD_DEPRECATED_SINCE and OO_ENABLE_DEPRECATED_SINCE, see documentation for explanation):


include(ECMGenerateExportHeader) set(EXCLUDE_DEPRECATED_BEFORE_AND_AT 0 CACHE STRING "Control what part of deprecated API is excluded from build [default=0].") ecm_generate_export_header(foo VERSION ${FOO_VERSION} EXCLUDE_DEPRECATED_BEFORE_AND_AT ${EXCLUDE_DEPRECATED_BEFORE_AND_AT} DEPRECATION_VERSIONS 5.0 5.12 )

Installed header foo.hpp:

#include <foo_export.h> enum Bars { One, #if FOO_BUILD_DEPRECATED_SINCE(5, 0) Two, #endif Three, }; #if FOO_ENABLE_DEPRECATED_SINCE(5, 0) /** * @deprecated Since 5.0 */ FOO_DEPRECATED_VERSION(5, 0) void doFoo(); #endif #if FOO_ENABLE_DEPRECATED_SINCE(5, 12) /** * @deprecated Since 5.12 */ FOO_DEPRECATED_VERSION(5, 12) FOO_EXPORT void doBar(); #endif class Foo { #if FOO_BUILD_DEPRECATED_SINCE(5, 12) /** * @deprecated Since 5.12 */ FOO_DEPRECATED_VERSION(5, 12) virtual void doFoo(); #endif

Source file foo.cpp:

#include "foo.hpp" #if FOO_BUILD_DEPRECATED_SINCE(5, 0) void doFoo() { // [...] } #endif #if FOO_BUILD_DEPRECATED_SINCE(5, 12) void doBar() { // [...] } #endif #if FOO_BUILD_DEPRECATED_SINCE(5, 12) void Foo::doFoo() { // [...] } #endif Other, better approaches?

The author is not aware of other approaches currently, but would be happy to learn about, to compare, improve, or even discard in favour of another the proposed approach.

Please also have a look at the documentation for the proposed CMake macro ECMGenerateExportHeader (review request) and tell your thoughts.

For this macro being applied, see a patch for KCoreAddons and a patch for KService.

Kate Planning

Monday 9th of September 2019 03:44:00 PM
The Opportunity

During Akademy 2019 here in Milan, Dominik and me had time to sit together and discuss a bit what we shall do to evolve Kate :)

Whereas Kate already works well as a general purpose editor, the competition in the text editor space got more intense in the last years.

Beside the well established stuff like GNU Emacs & Vim, new editor projects got started that did set the bar higher on what users expect from a advanced GUI text editor.

For example Sublime, Atom and Visual Studio Code are things to keep an eye on feature & polishing wise.

Therefore we decided it would make sense to think a bit about which stuff should be improved or altered in the near future.

The Rough Ideas Kate Plugin Interfaces

From the KDE 4.x Kate to the KF5 based Kate version, we removed the Kate specific plugin interfaces and went with more generic interfaces in KTextEditor.

The idea was to be able to share more plugins e.g. between Kate and KDevelop. This idea never really did take off, at the moment just two of our plugins are shared at all…

On the other side, this makes it much harder to expose new functionality to our plugins, as we need to stay binary compatible.

Moving back to having some Kate only stuff that has not even installed headers but is just usable for the plugins we bundle in our kate.git will make it again more flexible what to expose.

One can still think about moving “proven in practice” parts back to the KTextEditor interface part.

Make Projects a Core-Feature

At the moment the projects feature is located in a plugin.

For exposure of some things like the current project files some evil Qt property hacks are used.

By moving this feature into the Kate core we can use a sane way to search in project, list project stuff in quick open, …

Other state of the art editors provide that per default, too

Still stuff like “shall we create projects on the fly” can be deactivated like today

LSP Support per default

We shall get the LSP support in a shape that it can be shipped enabled per default.

Users expect that modern editors provide advanced language integration off the shelf, like Atom, Visual Studio Code, …

Great code navigation

We shall provide the user with better code navigation.

We will provide the plugins with an interface to register location jumps.

This will enable the user to seamlessly jump back and forth for any kind of location change e.g. due declaration lookup or search in files match lookup, …

Consolidate the plugins

The new LSP plugin shall subsume stuff like the Rust or D specific code completion plugins.

Think about the future of unmaintained plugins!

External Tools Plugin

Revive the external tools in a improved way, e.g. like in Qt Creator.

Improve Port to KSyntaxHighlighting

Porting the highlighting over to KSyntaxHighlighting was a big success.

Kate and Qt Creator now finally share the same highlighting engine and we got a lot of new contributions to our highlightings. (we support now over 300 different languages, something to be proud of)

Still, e.g. the theme support is still not moved over to what the new framework provides.

Further Brainstorming Git Integration

We shall take a look what other editors provide.

Diff/Patch Viewer

Want we to integrate with stuff like KDiff3/Kompare/… to have a better handling of e.g. git diff, patches, …?

Improve View Management

Try to improve the way we handle splitting the views and the tabbing.

Take a look how other editors do that!

KDevelop vs. Kate?

Given already today we enter the area of KDevelop by providing the LSP client, we need to think about what happens in the future with overlapping features.

It is no goal to evolve Kate into an IDE.

We think Kate shall be a competitor for editors like Atom, not for full-fledged IDEs like KDevelop or Visual Studio.

Still, e.g. in the area of project management/code navigation/version control support there will be some overlap.

The question is: can we share stuff there? What shall be the focus of Kate and KDevelop in e.g. language support?

I think here it will be interesting which future direction the KDevelop project will take.


If you want to chime in on this, feel free to join the discussion at the KDE reddit.

If you want to contribute, just join us at or on

Sketchnotes at Akademy 2019

Sunday 8th of September 2019 05:07:00 PM

The conference part of this year’s Akademy is now over. Like last year, I did live sketchnoting of all the sessions I attended.

Obviously, the first keynote from Lars talking about the Qt 6 plans was very important for the community and I think I did an adequate job there:

I don’t think I made the KDE e.V. Board Report shine… sorry about that, but that’s again a very important community landmark:

The second keynote about Open Source in Italian Public Administrations was also interesting and the sketchnotes ended up not too bad:

As far as sketchnoting goes, I think the one I’m the most proud of this year is the one done during the KPublicTransport session (the talk was very interesting as well, good content):

And finally, like last year, the lightning talk session was very challenging. I think it’s in part due to the fast pace of the talks. Since the session was shorter though (it was only 4 talks) I decided to constraint myself to a single page for all of them. I think it was worth it and I’m happy with the result:

If you want to see more (there’s almost 20 of them, I didn’t list them all here), the full list of sketchnotes are in the Akademy 2019 gallery.

I hope you like them and will find them useful. As usual they give a different perspective on the conference content.

Introducing Kirogi: A ground control application for drones

Sunday 8th of September 2019 12:16:16 PM
KDE Project:

Today I'm in beautiful Milano, Italy, where the KDE community has gathered for its annual user and developer conference, Akademy. At Akademy I've had an opportunity to present my new KDE project to a larger audience: A ground control application for drones, Kirogi.

Kirogi's direct flight controls screen

Kirogi aims to enable the operation of drones of all sorts of makes and models in an approachable and polished manner, with both direct and map-based control modes and many more features planned for the future.

The origin story behind the Kirogi project is a classic open source tale. During this year's Lunar New Year holiday, I was paying a visit to family in Busan, South Korea (the name Kirogi is Korean and means wild goose). During the off-days I ended up buying my first drone. I attempted the first flight in my mother-in-law's living room. Unfortunately the official vendor application immediately started crashing after take off - much to my embarassment, I couldn't land the thing! Eventually it slowly drifted towards a very nice armchair (sorry mom!) and crashed on contact with an emergency engines-off.

Turns out the app I was using had been replaced by a newer, seperate app store upload intended for a newer drone - and the app I had wasn't fully compatible with a newer version of the phone's OS anymore. I realized open source can serve drone owners better there and started hacking on this new KDE application a few days later.

Since then I've received a lot of support and help from many people in the fantastic KDE community, including Krita-powered artist L. 'AsmoArael' C., who responded to a request I posted KDE's Artists Wanted forum and helped me realize Kirogi's mascot:

Kirogi's mascot, a farm goose and technology enthusiast

If you want to know more about the project's origins and dive further into the technical details, I invite you to check out the slides for the talk I gave today. It was recorded on video as well; I will add a link once it's been made available.

The project also has a website already. Along with much additional information on the project it features download links for nightly development builds.

Finding the Edge

Sunday 8th of September 2019 11:42:20 AM

Three months of fighting with boost, qt, having a proper plan, multiple individuals to get help from and still unable to hit the target in time. That will be software engineering 101 for me.

KDE e.V. wants you!

Sunday 8th of September 2019 09:20:00 AM

At the moment, the yearly KDE conference Akademy is taking place in Milan. The yearly KDE e.V. meeting will be tomorrow.

KDE e.V. is a registered non-profit organization that represents the KDE Community in legal and financial matters.

For example the KDE e.V. is responsible for paying the servers that run our Phabricator/Bugzilla/Gitlab instances and all our web sites. KDE e.V. takes care of sponsoring developer sprints and contributor travel costs, too.

If you are a KDE contributor, consider to join the e.V. to get some vote about its direction.

If you want to join, just take a short look at this guide.

KDE Usability & Productivity: Week 87

Sunday 8th of September 2019 02:51:22 AM

This is the last week in KDE’s Usability & Productivity initiative (next week the blog posts will continue, but under a new name). The voting results are in for KDE’s new goals and the community-selected winners are full Wayland support, UI consistency, and a renewed focus on KDE apps. Read all about it here!

But meanwhile, there’s a ton of stuff to announce right now, so let’s jump right in.

Serendipitously enough, something big landed this week that’s relevant to the first new goal: fractional scaling on Wayland!!!

Check out the complicated dependency tree of patches that were required to make this happen:

Veteran KWin developers Roman Gilg and David Edmundson have been working on this for ages, and all of their hard work–which will land in Plasma 5.17–is much appreciated. But wait, there’s more!

New Features Bugfixes & Performance Improvements User Interface Improvements

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If you find KDE software useful, consider making a tax-deductible donation to the KDE e.V. foundation.

digiKam 6.3.0 is released

Sunday 8th of September 2019 12:00:00 AM

Dear digiKam fans and users, We received a lot of excellent user feedback after publishing the third digiKam 6 release in August 2019. We are now proud to briefly announce the new digiKam 6.3.0, a maintenance version which consolidates this feedback and acts as an important phase of this 3-year-old project. New GMic-Qt plugin for Image Editor Since digiKam 6.1.0, we open digiKam to external contributions with a collection of new plugin interfaces, named “Generic” for album items processing and export to web-services, “Editor” to extend Image Editor and Showfoto post processing, and “Bqm” to add new tools in Batch Queue Manager.

AqBanking and certificates

Saturday 7th of September 2019 07:25:04 AM

It has always been a mystery to me, why the AqBanking/Gwenhywfar library used for online banking in KMyMoney complains about the validity of certificates because it cannot check the signer when all other software on my system has no problem with that, even with the same servers.

Up until now, I simply checked the signer manually using some openssl tools and accepted the certificate within AqBanking. Now that it happened to me that I moved to a new system, the complaints popped up again and I sat down to figure out what the problem really is and how to solve it.

Apparently, each Linux distro has their own way of storing the certificates. Some are based on a single file containing all of the certificates simply concatenated, some others rely on single files in a directory. Also, the location of these files and dirs is different among the distros.

Not knowing where AqBanking is searching for certificates, I ran

strace -e trace=%file -o cert.log kmymoney

and I found the following section in the cert.log file after I saw the dialog with the complaint:

openat(AT_FDCWD, "/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr", {st_mode=S_IFDIR|0755, st_size=104, …}) = 0
stat("/usr/share", {st_mode=S_IFDIR|0755, st_size=5498, …}) = 0
stat("/usr/share/ca-certificates", 0x7fff91f0cb30) = -1 ENOENT (No such file or directory)

It seems, that it only looks in two locations and my distro does not keep the certificates in them. So far, so good. Since I build Gwenhywfar with the –enable-system-certs setting, I built it again without that setting just to find out that it does not make a difference with respect to my problem.

Next I studied where the openSUSE distro expects the certificates and found some useful information in /usr/share/doc/packages/ca-certificates/README:

The canonical source of CA certificates is what p11-kit knows about. By default p11-kit looks into /usr/share/pki/trust/ resp /etc/pki/trust/ but there could be other plugins that serve as source for certificates as well.

The next paragraph in that file talks about legacy systems:

update-ca-certificate supports a number of legacy certificate stores for applications that don’t talk to p11-kit directly yet. It does so by generating the certificate stores in /var/lib/ca-certificates and having symlinks from the locations where applications expect those files.

Cool, that is it, but why is it not working for me? Well, the locations that are supported out of the box are not the ones AqBanking is using.

  • /etc/ssl/certs: Hashed directory readable by openSSL. Only for legacy applications. Only contains CA certificates for server-auth purpose. Avoid using this in applications.
  • /etc/ssl/ca-bundle.pem: Concatenated bundle of CA certificates with server-auth purpose. Avoid using this in applications.
  • java-cacerts: Key store fore Java. Only filled with CA certificates with purpose server-auth.
  • openssl: hashed directory with CA certificates of all purposes. Your system openSSL knows how to read that, don’t hardcode the path! Call SSL_CTX_set_default_verify_paths() instead.

Hmm, the contents of /etc/ssl/ca-bundle.pem looks very similar to what is kept in /etc/ssl/certs/ca-certificates.crt in other distros. I am a bit adventurous today, so I thought a simple

sudo ln -s /etc/ssl/ca-bundle.pem /etc/ssl/certs/ca-certificates.crt

can help. And in fact, it solved the problem of the unknown signer.

Now I have to find out, why AqBanking/Gwenhywfar always wants me to manually accept an institution’s certificate before I can use it. Or is this by design?

I'm travelling to Akademy

Saturday 7th of September 2019 06:00:00 AM

I’m writing this post on the train from Rome to Milan, but I guess better late than never. I’ll be in the city all week and I will host a Dolphin BoF on tuesday.

See you! :)

More in Tux Machines

today's howtos

Audiocasts/Shows/Screencasts: FLOSS Weekly, Containers, Linux Headlines, Arch Linux Openbox Build and GhostBSD 19.09

  • FLOSS Weekly 551: Kamailio

    Kamailio is an Open Source SIP Server released under GPL, able to handle thousands of call setups per second. Kamailio can be used to build large platforms for VoIP and realtime communications – presence, WebRTC, Instant messaging and other applications.

  • What is a Container? | Jupiter Extras 23

    Containers changed the way the IT world deploys software. We give you our take on technologies such as docker (including docker-compose), Kubernetes and highlight a few of our favorite containers.

  • 2019-10-16 | Linux Headlines

    WireGuard is kicked out of the Play Store, a new Docker worm is discovered, and Mozilla unveils upcoming changes to Firefox.

  • Showing off my Custom Arch Linux Openbox Build
  • GhostBSD 19.09 - Based on FreeBSD 12.0-STABLE and Using MATE Desktop 1.22

    GhostBSD 19.09 is the latest release of GhostBSD. This release based on FreeBSD 12.0-STABLE while also pulling in TrueOS packages, GhostBSD 19.09 also has an updated OpenRC init system, a lot of unnecessary software was removed, AMDGPU and Radeon KMS is now valid xconfig options and a variety of other improvements and fixes.

MX-19 Release Candidate 1 now available

We are pleased to offer MX-19 RC 1 for testing purposes. As usual, this iso includes the latest updates from debian 10.1 (buster), antiX and MX repos. Read more

The Linux Mint 19.2 Gaming Report: Promising But Room For Improvement

When I started outlining the original Linux Gaming Report, I was still a fresh-faced Linux noob. I didn’t understand how fast the ecosystem advanced (particularly graphics drivers and Steam Proton development), and I set some lofty goals that I couldn’t accomplish given my schedule. Before I even got around to testing Ubuntu 18.10, for example, Ubuntu 19.04 was just around the corner! And since all the evaluation and benchmarking takes a considerable amount of time, I ended up well behind the curve. So I’ve streamlined the process a bit, while adding additional checkpoints such as out-of-the-box software availability and ease-of-installation for important gaming apps like Lutris and GameHub. Read more