LibreOffice and Plasma easing the use of GTK apps on the KDE desktop
At KDAB, we know that consistency is an important aspect of the User Experience – users don’t want to have to learn different ways to achieve the same thing. In the Linux world, there is a major structural pitfall to this: the applications written for Linux come in at least two major technologies – Qt and GTK. Each of these frameworks deeply influences the experience the user has, and in different ways. As you’d expect, the frameworks have their own helper-dialogs e.g. to open or save a file or for printing. This can make it confusing for users, when the apps they use don’t show the same helper-dialogs for common actions.
Most KDE software is written using the Qt library, and within KDE there are lots of attempts to ease the use of GTK applications on Plasma, the KDE desktop. For example, GTK has been styled by members of the KDE community so its applications are visually consistent with the overall KDE look. Nonetheless a major drawback to these efforts remains: helper-dialogs opened from a GTK application are still GTK dialogs and they function differently.
For the user this inconsistency is annoying. Take file handling for example: KDE offers a lot of support to the user. They can define important places – like favorite folders, drives, cloud storage – that allow fast access whenever the user needs to handle files. It follows the KDE idea of navigation through the files, which includes how the user navigates, handling file previews and how the files in a folder are filtered. The file open dialog in GTK is not worse than the KDE one, it is just different. It offers almost the same functionality, but is presented in a way the KDE user is not used to. This can be confusing and frustrating, especially in environments where the user has no choice about the system they have to work with.
Perhaps the best known and most commonly used GTK application is LibreOffice. The limitations it has for KDE users due to the use of GTK dialogs is well known to the LibreOffice community. A lot of effort has already been undertaken to fix this problem. Some ideas even went so far as to migrate large parts of LibreOffice to Qt in order to provide a native feeling for KDE users.
KDAB is a partner for the City of Munich which has installed open source software for all its employees. It runs a KDE-based desktop called Limux for which KDAB provides support. You can see the full story about our work with Limux and the City of Munich here. The City of Munich provides LibreOffice as its Office Suite, so the employees of the City of Munich asked KDAB if we could find a way to fix the problem described above. After some head scratching, we found a successful solution.
The short version is, we found a way to open the KDE dialogs from within LibreOffice so the user experience is seamless – the employees can just get on with their work without being troubled by the software.
How we did it
The overall effort to port LibreOffice to Qt is a huge undertaking. What’s more, actually maintaining the code afterwards, is even more work. Could we do something else instead? Turns out, there is prior art here – the KDE/Plasma integration for Firefox! As such, it was decided to first investigate whether a similar hack could achieve a good-enough solution for the short-term in LibreOffice: Use the well-maintained GTK LibreOffice code base, style it with the above-mentioned KDE widget style for GTK, and then intercept calls to open the GTK file dialogs and instead show the KDE file dialogs.
The latter part is, sadly, not as easy as one may first believe, since running both GTK and Qt within the same application can lead to nasty side-effects: Accessing the clipboard through two distinct X11/xcb connections, once from GTK and once from Qt, from one and the same application, can easily deadlock for example. To work around this problem, we moved the KDE file dialogs into an external helper process. This approach has already proven successful for Firefox in the past. As such, it was mostly a matter of reimplementing it for the specific needs of LibreOffice. And, once again, the approach yielded good results and the patches for LibreOffice were also accepted upstream!
Although this is a bit more of a hack than we would normally do, it works! And we believe that, overall, this integration approach is less work in the long term than porting LibreOffice fully to Qt and maintaining it alongside the GTK layer. What’s more, as this is an open source project, all of our efforts have been upstreamed and will be available for all LibreOffice users under KDE, not only the employees of the Munich City Council.