Discover: Open desktop ratings

17.3.2017 - jgrulich 3 Comments

As I’m trying to keep improving the flatpak backend in discover I decided to add support for reviews. To do so I implemented support for GNOME’s Open Desktop Ratings which is rating/review system used by gnome-software. Result of this is now fully functional review system, where you can read user comments and ratings and submit your own reviews. We also use same mechanism as in gnome-software for generating user_hash which identifies you in odrs server and given that you are able to modify/delete your reviews from both discover and gnome-software (note that discover doesn’t support this yet). You can also vote for already existing reviews so others get feedback on how useful each review is. We also decided to use same review system in our PackageKit backend and replace current Ubuntu Popularity Contest system so not only flatpak users will benefit from this. During testing of this review support we’ve hit many UI issues related to review system causing users not to be able see reviews or write new ones which were introduced during transition to kirigami. We fixed all of them and you can look forward to improved experience in the upcoming discover release. To improve this further, we or at least I, would like to also add a new widget showing current total app ratings as of now you can only see reviews with comments only, not overall app rating, but this needs some discussion and design consideration.

Here are some screenshots to prove that this is already working:

If you want to test it, which we would like you to do, you can just compile discover from master branch (with -DBUILD_FlatpakBackend=ON cmake parameter for flatpak support). That’s all from me for now. Have a nice weekend :).

Telegram desktop client for flatpak #2

23.2.201715.4.2017 - jgrulich 31 Comments

Some time ago I posted a blog post about how I packed telegram desktop client for flatpak. I’ve been updating it since then in some reasonable intervals as I don’t have time to update it more often and mostly because the telegram client’s build system breaks my build quite oftenly. Recently I discovered that someone managed to patch telegram to use system Qt libraries instead of building own patched Qt and building linking it statically. After some time I managed to adjust those patches and make them work with my build which allows me to use Qt from KDE runtimes. Here are new instructions how to get this work:

Add KDE runtimes repository and install runtimes
$ flatpak remote-add kde --from https://distribute.kde.org/kderuntime.flatpakrepo $ flatpak install kde org.kde.Platform

And then you can install and run the telegram desktop client:
$ wget https://jgrulich.fedorapeople.org/telegram/keys/telegram.gpg $ flatpak remote-add --gpg-import=telegram.gpg telegram-desktop https://jgrulich.fedorapeople.org/telegram/repo/ $ flatpak install telegram-desktop org.telegram.desktop $ flatpak run org.telegram.desktop

Or install it from bundle
$ wget https://jgrulich.fedorapeople.org/telegram/telegram.flatpak $ flatpak install --bundle telegram.flatpak

The reason I did the hard work to build it with Qt from KDE runtimes is that now you can use telegram with portals support if you run it with “-platform flatpak” parameter. Unfortunately this only makes openURI portal to work as telegram has some internal hacks or whatever to use gtk filedialog so for that reason I still allow to access user’s home directory. There is also a bug if you use telegram under KDE where it tries to use QSystemTrayIcon instead of libappindicator and unfortunately telegram’s system tray icon (the one using QSystemTrayIcon) works only with Qt 5.6.2 and in KDE runtimes we have Qt 5.7.1. The system tray icon is visible, but its context menu doesn’t work so if you want to have fully working system tray icon you have to use “–env=XDG_CURRENT_DESKTOP=gnome” flatpak parameter to force it to use libappindicator.

And that’s it. Sorry you had telegram broken for couple of days while I was fighting with it, but hopefully it will work perfectly now.

KDE Discover flatpak backend

14.2.2017 - jgrulich 6 Comments

As some of you might already know, I’ve been focusing lately on Flatpak and its integration into KDE. You can check my work on Flatpak KDE portals, which are being currently included in our KDE runtimes and repositories were migrated to KDE git so there has been made some progress since last time I talked about them. Recently I started looking into adding Flatpak support to KDE Discover, to have same support for Flatpak as Gnome has with gnome-software. From the begining it was a nightmare for me as I have never used any glib based library so that slowed me down little bit. I also went through gnome-software code to understand how flatpak integration is done there to get some inspiration. Things went well since then and I have already quite nice stuff to share with you. We currently support most common functionality, like listing available/installed flatpak applications in Discover with possibilities to install/remove/update and of course launch them. We also support flatpak bundles and flatpakref files already. If you don’t believe me then here are some screenshots:

This is quite exciting stuff for me. There is still plenty of things we need to solve and improve, as well as adding possibility to manage flatpak repositories which is quite important feature to have too. This all is already possible to try in master branch of discover, you just need to enable flatpak backend. We will keep intensively working on this and hopefully we will have fully functional flatpak support in Discover soon and ready for the next Plasma release. See you soon!!.

KDE Flatpak portals introduction

18.1.201718.1.2017 - jgrulich 2 Comments

I guess you all have heard about Flatpak, Snappy and sandboxing in general. Flatpak is a new way of distributing applications. With Flatpak applications are running in sandbox, which means they are isolated from the rest of your system. With that in mind you need a way how to access some stuff outside the sandbox, like your files or have access to your hardware. To solve this problem the Flatpak developers came up with portals. Portals are high-level session bus APIs that provide access to resources to sandboxed applications. Idea is that there is one DBus service available and visible for the sandboxed application which is supposed to communicate with it to get access outside the sandbox. Then this one service communicates with backend implementations which may be different per desktop so you have in example a Gnome implementation or in my case KDE implementation. The backend then provides dialogs so users can access files or hardware outside the sandbox. To add portal support you need to add your backend implementation, which is quite easy part and if you don’t have any then one from other available ones will be used. Complicated part is to alter the framework the application is using to use the portal DBus service instead of doing what it usually do (e.g. when opening a file dialog you want to send a request over DBus instead of actually displaying the dialog). I’ve been playing with this for some time and I tried to cover the most common or required portals. Let’s go through all of this:

File chooser portal

I think this is the most common and needed portal from all of them. I’ve added a backend implementation as well as support for this to Qt in form of my own Qt platform plugin. Given you can modify Qt’s behaviour using your own Qt platform plugin then I didn’t have to modify Qt at all. The platform plugin alters FileDialog to talk around DBus instead of showing the dialog. The dialog is then shown thanks to the backend implementation and user running app in sandbox shouldn’t notice any difference. The file chooser portal supports both opening and saving files with possibilities to set properties like filters, accept label text etc. which are all already implemented in both like in the platform plugin and the backend.

App chooser portal

This portal allows the user to select an application outside the sandbox which should be used for opening a document, a file or whatever. It is also used when opening an url. On the backend side this is just a simple dialog with list of possible applications associated with given file/document type. On Qt side I added my own implementation of OpenUrl() again into the platform plugin to make it transparent the same way the file dialog works.

Print portal

I guess the most complicated and also quite important portal. I’ve been able to add just backend implementation so far which will be used for printing from gtk applications as gtk already supports printing from sandbox. The idea behind this portal is that when app requests to print a document, it calls PreparePrint() method and the backend presents classic print dialog to the user where he can configure printer, setup the page and paper and so on. This configuration is then passed back to the application where the framework is supposed to create a pdf or ps file already pre-formatted and ready for printing. This file is then passed as file descriptor again to the backend using Print() method and printed. This all works with Qt backend and gtk app, or Gnome backend and gtk app, but unfortunately not yet with Qt apps as I still don’t know how to do this without touching Qt code as this cannot be done on platform plugin level, at least from what I can see. A simple solution can be to don’t touch Qt at all and let the app print the document to file and have a simple utility sending this file through the portal to print it. As you can set application name which should be used for printing in QPrinter, then we maybe can just set this automatically when the app is running in sandbox to make this work automatically. I’m definitely open to your ideas or any help :).

Notification portal

Again very useful portal and not that complicated. I have full backend implementation presenting a notification outside the sandbox when someone calls AddNotification() method. To make this work for KDE applications automatically I had to modify KNotifications framework and implement my own flatpak plugin which replaces NotifyByPopup plugin. All this plugin does instead displaying a popup it calls the portal DBus service which then calls AddNotification() in my backend and presents notification outside the sandbox. Both the plugin and backend supports also sending back information about triggered action so you can also get feedback back to the sandboxed application.

Those are all the portals I have fully or partially covered so far. There are of course more portals designed in Flatpak portal API, like screenshot portal, inhibit portal, but for some of them we don’t have any framework/API or they are not that important so they will be added later. I also have a test application which you can run in sandbox and test all the portals.

How to use flatpak portals

In order to use flatpak portals, either my implementation or the Gnome one, you need to install xdg-desktop-portal which is the main portal DBus service visible to sandboxed applications and which calls backend implementation. For gtk implementation you need xdg-desktop-portal-gtk and for KDE/Qt implementation you need xdg-desktop-portal-kde. This is required to be installed outside the sandbox to present dialogs for file and hardware access. To add support for portals to your sandboxed application you should be fine already with gtk, with Qt and KDE you need my Qt platform plugin and my modifications made to KNotifications. To use those you need to modify flatpak manifest to include them during build so they are available in the sandbox. You can get inspiration in my test app manifest. And finally to use my platform plugin as KNotifications will be used automatically you need to start your app using flatpak run your_app -platform flatpak.

I guess that’s all from me today. Patches and improvements are warmly welcomed as well as any reported issue. If you want some information about Flatpak and KDE in general, we have setup a wiki page where you can find information about KDE runtimes and applications packaged for Flatpak. There will be also a talk at FOSDEM this year about Flatpak and KDE from Aleix Pol.

Introducing new KCM for network configuration

28.11.2016 - jgrulich 13 Comments

After several attempts trying to write a new KCM for network configuration and actually not finishing any of them, I decided to start one more time, but this time my goal was to simply transform the old editor into a bit nicer KCM and place it into system settings where this was missing for very long time. You can see my current result below.

This is still same editor as it was existing before as a standalone application, except the list of connections is now written in QML and is similar to the applet we have in systray. I also had to rewrite the editor widget a bit because it’s currently implemented as a dialog with a tabwidget inside where each tab is represented by one setting widget (e.g. Ipv4SettingWidget), For the new KCM we now have ConnectionEditorBase widget doing all the logic behind, like creating specific setting widgets based on connection type and so on. This widget alone doesn’t display anything and you have to actually subclass it and reimplement method taking care of layouting. This allows me to have e.g. ConnectionEditorTabWidget which just subclasses ConnectionEditorBase and reimplements addWidget() method to place setting widgets into QTabWidget. In future we can also simply write a new UI/layout on top ConnectionEditorBase widget and get rid of the tab layout.

Regarding functionality, it should be already almost on par with functionality of the editor. There are still some missing features (like import/export of VPN), but besides that I think everything else is going well. With the new KCM there are also some minor improvements, like you can now reset your not-saved changes you made to a connection. My plan is to get this into Plasma 5.9 which is supposed to be released in january so I still have plenty of time to finish missing features and address issues I made during this transition and of course time to take your comments into account and make this KCM as most usable for everyone I can :).

I’m going to Akademy 2016

29.8.2016 - jgrulich Leave a comment

This year I’m giving a bit technical talk called “Bring NetworkManager support to your Qt applications” where I would like to share with you possibilities of NetworkManagerQt framework. I also host a BoF on Monday about Flatpak, where I plan to discuss mostly KDE Flatpak portals so anyone interested in this topic is welcome. Aaaand to be honest, I wrote this blog post just to be able to use the lovely “I’m going to Akademy” banner. See you in Berlin!!

Telegram desktop client for flatpak

8.7.201620.7.2016 - jgrulich 10 Comments

Since everyone is talking about flatpak or snappy these days I wanted to try it myself and package some application. I decided to start with telegram desktop client which was suggested to me as an application which would be nice to have packaged for flatpak. Once I saw the build instructions for the first time I thought it’s going to be an impossible task and it almost ended with that result, but I didn’t want to give up. It took me three working days to go through all dependencies and to make it build as the telegram qmake file is written with all paths hardcoded and you need to build it exactly in a way the author intended. I could of course package the binary provided by the author itself, but my intention was to provide a way to test the latest git version. Given that, I think I managed to try almost everything flatpak-builder allows you to do and I have to say I quite enjoyed doing that, because if you want to package an application for flatpak you just need to write a manifest (json file) and declare runtime and sdk you want to use, thankfully upstream already provides most common runtimes you need. Then you just need to define dependencies one by one, where for each of them you can specify whether it should be cloned from git, or if it should be downloaded as an archive or you can even use special type of source called “shell” where you can specify shell commands you want to run. Then flatpak-builder will automatically run configure (or another command you specify, like qmake) , make and make install on every source you define with build parameters you define. This everything is pretty automatized and re-running the build will skip stuff you have already built successfully before or you downloaded before. For most applications writing this manifest is relatively easy and in case you don’t need any specific library which is not provided by any available runtime you can do that pretty fast, even if you do it for the first time, just get some inspiration in another manifest for a similar application and that’s all you need.

To try the telegram desktop client I made the repo created by flatpak-builder available.
You just need to get Gnome runtime first:
$ wget https://sdk.gnome.org/keys/gnome-sdk.gpg $ flatpak remote-add --gpg-import=gnome-sdk.gpg gnome https://sdk.gnome.org/repo/ $ flatpak install gnome org.gnome.Platform 3.20

And then you can install and run the telegram desktop client:
$ wget https://jgrulich.fedorapeople.org/telegram/keys/telegram.asc $ flatpak remote-add --gpg-import=telegram.asc telegram-desktop https://jgrulich.fedorapeople.org/telegram/repo/ $ flatpak install telegram-desktop org.telegram.TelegramDesktopDevel $ flatpak run org.telegram.TelegramDesktopDevel

You can of course build it yourself as well or if you want just check the manifest you can find it here:
https://github.com/alexlarsson/nightly-build-apps

Introducing plasma timekeeper – an applet measuring your activity

11.3.2016 - jgrulich 20 Comments

Have you ever wondered how much time do you spend reading emails, browsing on internet or hacking? I have! I started thinking about monitoring my activity. Reason for this was that I work from home, where I’m alone and nobody is behind my back watching what I’m actually doing. So I came with an idea to write a simple applet which tracks the time you spent in a certain application by just checking your currently active window (application). The functionality is pretty simple, you switch focus to a window where you do something, the applet starts measuring the time and update it in some interval until you switch to another window and so on. It may not be accurate in case you will be cheating, e.g. you open a video player and start watching a movie while you switch focus to another app to avoid monitoring time spent in the video player. Given this, the purpose of the applet is pretty obvious, it should be just for you, for your personal usage when you have no reason for cheating, because you are interested in these statistics.

Here are screenshots of the current version:

The applet has a compact version which you can put into your panel, it shows the current active window and the time you spent in there. Once you click on it, it will popup a window showing a list of all applications you used ordered by usage. To extend the basic functionality I added buttons to start/stop monitoring, a button to reset the current statistics (there are even options to reset the statistics on suspend/reset/shutdown in applet configuration) or buttons to blacklist applications you don’t care about.

For those who are interested in trying this little project of mine or they want to contribute and extend it, fix something or report an issue, here’s the link.

Upcoming news in Plasma 5.5

8.11.201524.2.2016 - jgrulich 11 Comments

It’s been a while since Plasma 5.4 release and we are now approaching feature freeze for Plasma 5.5 so I would like to share with you what news you can expect in plasma-nm. This time we have major changes only in our connection editor although most of you wouldn’t probably even notice them. This is going to be a short list unfortunately given I have less time and less ideas, but at least something, right?

So, what is new?

WPA/WPA2 Enterprise validation
WPA/WPA2 Enterprise validation was the only one missing validation in our connection editor and without it we let you to save your WPA/WPA2 Enteprise configuration even when it was wrong or some option was missing. Now you should be able to save your configuration only when it’s valid for NetworkManager. In addition to check for missing properties, we check (in case of TLS authentication) whether provided private key can be decrypted with given private key password (works only for pkcs12 and PEM formats).

New password field widget
Option to show/hide the password and option to not store the password were removed as standalone widgets and they are now part of the password field. I did this to make the UI less complicated and also because I like it, however this introduced some accessibility issues which need to be addressed somehow once I have time to do that (mentioned this here as a commitment that I’ll really do something about that).

Other changes

OpenVPN improvements (better properties descriptions, new options)
added tooltips to most common options
some bugfixes and other minor improvements which are not worth mentioning

Akademy 2015

3.8.201524.2.2016 - jgrulich Leave a comment

Akademy is the annual world summit of KDE which was held this year in A Coruña. I was there since July 22 until last Friday July 31 and even these ~10 days were not enough :). The official start was on Friday July 24 with a pre-registration party, where all Akademy attendees could pickup their badges, have some food and mainly drink with people they haven’t seen for a long time or at all. This year organizers also managed to prepare a show for us in form of preparation of Queimada, which is a traditional Galician punch.

The next two days were dedicated to talks and started with a keynote presented by Matthias Kirschner. I tried to attend those which were interesting for me and I would say that the most interesting talk was presented by Sebastian Kügler, where he introduced a new mobile platform called Plasma Mobile. This is going to be interesting given the Android and iOS domination, but there is definitely some potential.

I also have to mention the talk about sandboxed applications presented by my RedHat colleague Daniel Vrátil. Dan explained what is a sandbox, how it works and what are the benefits of using sandboxes.

The end of the weekend was, as usual, dedicated to sponsor presentations and Akademy awards. This year the awards were given to the awesome VDG group because without them the Plasma 5 wouldn’t look so great, to Albert Vaca, who is the main KDE connect developer and to Millian Wolff for his work on KDevelop. The last awards were given Scarlett Clark for her work on CI and to Akademy organizers.

Monday started series of BoFs. On Monday I attended only BoF organized by VDG to discuss the UI of the new traffic monitor feature in plasma-nm, which will be in Plasma 5.4.

On Tuesday we had Solid BoF for all developers working on hardware support for KDE. Unfortunately only few people showed up and nobody came to complain. This could be because people don’t know what Solid is or, in better case, everything works as it should. We discussed the current state of various Solid projects and mostly went through plasma-nm issues and missing features and Lamarque also decided to pass on his network management maintainership to me :).

In the evening the same day we had a party. The party was on the terrace of one shopping centre near the venue and was perfect until it started to rain. Then we had to move to a smaller place which was not suitable for so many people, but we enjoyed it despite those minor problems. We were eating delicious food, drinking good wine and dancing at the end so the party couldn’t be better :).

On Wednesday we had a day trip. Originally we were supposed to have lunch at the Hercules tower and then go to the beach, but the weather forecast was not optimistic so the day trip was changed to go to the Aquarium first and then visit the Hercules tower.

During Thursday and Friday people are leaving so the attendance of BoFs is not that high as in previous days. I went only to KDE connect BoF just to see what’s going on with this interesting project.

And that’s probably all. This year’s Akademy was perfect and I’m really glad I could be there. The city was nice, the weather was almost perfect, people were friendly and organizers did really good job this year. Thank you all and see you next year!!

Jan Grulich

Fedora, KDE, Qt, C++, QML

KDE