LibreOffice and Plasma easing the use of GTK apps on the KDE desktop
05.07.2018
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 one of the best known and most commonly used applications using GTK on Linux is LibreOffice. While there are multiple backends in LibreOffice, including ones for Qt and KDE, the GTK backend is used by default on most Linux distributions. 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’s contribution
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.
Great!!
Good news, but do you know when this menu’s will be available to the users of LO?
It’s going to be part of LO 6.2 afaik.
when will this be available?
(in which LO version??? Hope it’s 6.1…) 😀
No, sorry – it’s going to be part of LO 6.2 afaik.
One of the complains of the employees that partially lead to the Limux project being ended was the inability to use Limux software on tablets.
Had you not wasted your resources with LibreOffice and instead helped ironing out bugs in Calligra (which has a tablet interface), chances are you would not have lost a big client.
I hope you have learned your lesson and improve Calligra next time.
I think you are mixing up a few things here. First of all, I don’t think we wasted anything, considering how many people are using LibreOffice and KDE. Furthermore, we got contracted after the LiMux project was already cancelled, so we did not “lose a big client”. Finally, we will gladly improve Calligra, and we actually did work on a KF/Qt 5 port of Calligra Flow, but our customers have to decide what they want us to work on.
Great news!
I have a question, when you say “KDE/Plasma integration for Firefox!”, are you referring to the work done by the openSUSE team? If so, is the external process you mentioned similar to kmozillahelper?
Yes, that is exactly what I mean. Afaik the kmozillahelper is used by them too? the external process I integrated for LO is very similar, but it has some custom features specifically for LO.
That’s fantastic!
Hi ! That’s great news, indeed, thanks to all involved !
That’s slightly related, but as you mentioned the Firefox patches, I eventually always switch back to the vanilla version because on many random occasions the helper is not invoked and thus the files are not saved. I know other people have encountered this problem (for years literally :-). I’m way more confident, even with the same approach, in the case of Libo as those changes will be merged upstream. But indeed, this underlines your concern : after being implemented it will need to be maintained.
Cheers & thanks again for your efforts.
Yes, someone needs to maintain it. And I’m around to do that to some degree. I’m still convinced that it’s going to be less work than maintaining a full Qt port of LO/vcl.
Nice!
As you mentioned plasma-browser-integration, is there a possibility to also open Qt dialogs there? At the moment, Firefox’s open / save dialogs are also GTK+ ones.
There is a separate project for this, but the patches are not upstreamed into Firefox. Thus only some distros give you a Firefox with integrated dialogs, afaik Suse and Kubuntu are among these.
Wow, brilliant! I wish that Firefox would took such patches upstream thou. Somehow Chrome and Chromium can use KDE dialogs and only Firefox stands out.
Anyway, when we can expect those patches? I mean in which version they should be available?
Thanks for the kind words. I think it will be part of LO 6.2.
Thanks for all that good work!
Thanks a lot, and congrats. But I wonder why isn’t there some kind of standard that makes the content independent of its presentation, like in web design, where you have the content in one side and the CSS in other side.
I know that software engeneering is way more complex than web design, but a similar approach when it comes to GUI design would be the optimal (well, not really, I guess that the optimal solution would be that LO, FF, Gimp, & al. would move to QT, heheh).
The problem is that there exists no true cross-platform API for native applications, like HTML/CSS provide for browsers. Qt fills this gap quite nicely by abstracting away the native APIs, but indeed it would require usage of Qt from all the applications you mention.
What about today? It is going to be released the 7.2 release based on GTk 4 which takes benefit from hardware acceleration. Could a pure Qt LibreOffice be realized?
There is ongoing work by the community on a Qt5 port, but I’m not involved in that myself: https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=qt5