Last week I decided to take KDE Itinerary for a test tour. Between the train rides there was also time for some KDE stuff.
After writing an exam on Friday afternoon I took a train to Frankfurt. I did so not to enjoy the beautiful scenery of the area around Frankfurt central station at night but to be able to catch an early train towards Bruxelles for my first time at FOSDEM.
It has been a great experience to meet so many people interested in what KDE does at the KDE booth. It also was awesome to meet all the folks that are working hard on making Linux on the phone become a thing.
Plasma Mobile Sprint
FOSDEM went by in no time and so I found myself on a train to Berlin on Monday. My ride managed to defeat KDE Itinerary’s cancellation notification handling, but Volker managed to fight back.
In Berlin we met for a week-long Plasma Mobile sprint, hosted by KDAB in their offices. This gave us the opportunity to plan, discuss and hack all the things in a much more focused and productive manner than normally.
A particular pleasure was meeting Marius and Dalton from UBports/Ubuntu Touch and discussing how our projects can benefit each other. Most of our interactions was me nagging them to upgrade their Qt to allow KDE apps to run on Ubuntu Touch, but there was also fruitful discussion on sharing content between apps and a common push notification service (codenamed ‘Phushan’).
In addition to the discussion I also managed to get a few things done:
We managed to build KTrip using Ubuntu Touch’s clickable build system (only for amd64, since crosscompiling Qt is a little more involved. If you find it easy please consider applying at KDAB).
I started revamping the dated code of the dialer UI.
Together with the Kaidan team I fixed an issue in KNotifications that was affecting them.
Kaidan (XMPP client), Qrca (barcode scanner), Kookbook (recipe manager), Keysmith (OTP client) and Ruqola (Rocket.Chat client) are now available for Android in our nightly F-Droid repository.
On Saturday KDE joined UBports in their regular Q&A where we reported about the whole week and answered questions from the crowd. Check it out!
I left Berlin a bit earlier than planned due to an approaching storm, which was fine given how action-packed the whole week was.
Last week I took a train to Berlin for the KDE Frameworks 6 kickoff sprint. A lot has been said about it by my fellow attendees already, so I won’t go into detail much.
Work on Qt 6 has begun and with Qt 6 a version 6 of the KDE Frameworks is due. This will gives us the opportunity to clean up and redesign some of our API.
Main goal for the sprint was to discuss the major design principles for KF6. I personally focussed on two aspects. First, we want to better separate logic from the user interface to allow different UI implementations for desktop and mobile uses. Futhermore, we want to reduce the amount of dependencies our libraries have. While we are doing fine for a lot of frameworks some have very ugly dependency structures. Probably our worst offender here is KIO, the framework that powers Dolphin and many more KDE applications.
This is the current dependency tree of KIO:
With some changes we discussed applied it could look like this:
Please note that all of this is highly tentative and might not always work out the way we imagine. While we can do some of these changes in the Frameworks 5 lifetime already most of it needs breaking API, so it will only be available in KF6.
This work will hopefully make KDE Frameworks more appealing for users outside of KDE. If you are developing Qt-based software and would like to know more about how KDE Frameworks can help you please contact us at #kde-devel on freenode or firstname.lastname@example.org
From 19.6. to 25.6. I attended this year’s combined Plasma and Usability & Productivity sprint in the beautiful city of Valencia.
It was a great opportunity to meet old and new friends, drink beer and sangria on the rooftop and of course do some hacking.
First we discussed about the future development of Plasma, especially the Wayland experience. I was particularly interested in how we can solve the two missing pieces in KDE Connect on Wayland, Keyboard input and clipboard synchronization.
We did not only discuss things but got our hands dirty as well tough. I took the opportunity to work on several components, most of which I haven’t worked on much before:
I’ve reworked the system tray settings to be more concise and usable. Furthermore I worked on hiding certain system tray elements when they are not in a useful state, making the system tray less cluttered. I also fixed the appearance of the disk quota icon in the system tray settings and the system tray itself when using a dark theme.
As most of you know KDE Connect has recently been removed from Google Play due to a policy violation with regard to our SMS and telephony features. While the public outcry helped to get it back in with all features remaining this is just yet another example of how new Android policies make it harder for us to maintain the level of quality and features you expect from KDE Connect. Android Oreo forced us to drop support for older Android versions and imposed restrictions on background services which force us to have an annoying persistent notification. It is to be expected that Google will further restrict background services which will impose more problems for us. With each new Android versions new restrictions and problems arise which we have to work around, if possible. For example, the upcoming Android Q imposes restrictions on accessing the phone’s clipboard. It is unclear whether the clipboard sync in it’s current form is feasible on Android Q. Those are just examples of the problems with the direction Android is moving towards.
With Plasma Mobile KDE has been working on an alternative mobile platform for a while now. We now consider Plasma Mobile stable and suitable for everyone to use. Therefore we decided to stop developing KDE Connect for Android and focus on the Plasma Mobile experience. We have removed the app from Google Play and F-Droid as well as removed the public repositories. We are also in contact with Google about removing the active installations from devices.
We hope that this steps contributes to a better mobile experience in the long term beginning today, April 1st 2019.
My last post shows how to create a stub Python/Kirigami app that doesn’t do anything. Time to change that! In this post we’re filling the screen with some controls.
Kirigami apps are typically organized in Pages. Those are the different ‘Screens’ of an app. If you come from the Android world you can think of them as the view part of activities. In our case we want to have an initial page that offers to enter a stop or a destination and opens a new page that shows a list of possible routes. Clicking on one of the list items opens a new page with a detailed view about the connections.
Pages are organized in a pagestack where pages can be pushed and popped. On a phone only the topmost page is shown, whereas on a larger screen (desktop or tablet) multiple pages can be shown next to each other.
So let’s create some pages! I’m going put each page in its own .qml file and let the name end with Page. Our first version of StartPage.qml looks like this:
pageStack.initialPage is, well, setting the initial Page of the Page stack. Qt.resolveUrl is converting the relative URL of the QML file into an absolute one. Starting the app gives us an empty page
Time to fill it with some content.
On the start page we need need a way to enter start and destination of our journey as well as the date and time of our travel. For start and destination we are using simple TextFields from QtQuick Controls 2. Note that the older version 1 of QtQuick Controls is still around for the foreseable future, but we want to avoid using that. We’re extending StartPage.qml with our controls
A ColumnLayout is a component that positions its children vertically. We set it to be as wide as its parent, the page. The TextFields shall span the whole width as well. Instead of using the same ‘width: parent.width’ we are using ‘Layout.fillWidth: true’. This property is only available to children of a Layout. The difference to the first way is that all the width that is not already occupied by other elements in the layout is filled.
Next we need some way to enter a departure date and time. Unfortunately I’m not aware of any ready-to-use date and time pickers in QtQuick and Kirigami, so I’ll leave this open for a future post. For the time being two simple placeholder buttons shall be enough. Let’s add them to our ColumnLayout
Now our app looks like this. Both buttons have the “Layout.fillWidth” property set to true, resulting in each one getting 50% of the space.
The buttons look a bit weird, don’t they? That’s because they are using the built-in QtQuick Controls style. If you are using Plasma you are probably used to the org.kde.desktop style which emulates the active Qt Widgets style. We can force our app to use the org.kde.desktop style by running ‘QT_QUICK_CONTROLS_STYLE=”org.kde.desktop” ./main.py’
Looks closer to what we have on the desktop, doesn’t it? Qt also offers a ‘material’ style that follows Android’s material guidelines
Next we need a way to press “Search”. We could solve that with yet another button, but Kirigami offers another way. Pages in Kirigami can have Actions associated with them. The presentation differes from the phone to the desktop. On the phone actions are displayed on the bottom where they are easily reachable while on the desktop they are displayed in form of a toolbar at the top of the page. Let’s add an action to our page
KDE is happy to announce that we will be part of Google Summer of Code 2019. GSoC is a program where students recieve stipends to work on free software for 3 months. Getting paid for open source work, that’s the dream, right?
KDE Connect is participating with 3 interesting projects that also involve other areas of KDE
1. Improving KDE Connect on Windows
KDE Connect builds and runs on Windows, but there are a lot of things that can be improved. This mostly involves the functionality that makes use of notifications. A large part of this task is about improving KNotifications on Windows.
2. An SMS app for Plasma Mobile
Plasma Mobile does not have a functional SMS app yet. We believe that the best way to create one is to reuse the SMS UI we’ve been developing for KDE Connect. We verified that the Plasma Mobile SMS stack is functional on the Nexus 5 (I have no information about other devices). The UI is already running on a phone, what’s missing is a backend that talks to ofono
3. Barcode scanning infrastructure
Scanning a barcode is one of those tasks that comes up in various different apps but the developers don’t want to implement it themselves. For those kind of tasks we have the Purpose framework in KDE. It allows the developer to specify a desired action and let the user choose from available services to fulfil them. E.g. the Share feature in Dolphin is implemented via Purpose. This task is about adding a new action type to Purpose that allows to scan a barcode. Possible implementations could use the local camera or the camera of a device connected via KDE Connect.
If you are interested in doing one of those tasks and have some basic understanding of C++ please contact us on #kdeconnect on Freenode or on Telegram.
The deadline for student applications is April 9th and composing a good application takes some time, so please contact us rather soon.
Please note that we require students to have done some minor work (e.g bug fixes) before starting GSoC. Don’t worry if you don’t have done anything yet, there is still time for it 😉
From February 4th until February 9th I attended a Plasma Mobile sprint in Berlin, Germany. I met a lot of people that share the vision of an open, privacy-friendly mobile platform. However, we all agree that such a platform can only succeed if there are enough people sharing that vision creating suitable apps for it. There already is a nice amount of mobile-friendly Linux apps, many of them created by the KDE Community, but of course we need more 🙂
One app that is essential for my use case is an app that allows me to check departures and routes for public transport. Since I’m not aware of any existing one I decided to do my own and share my road here. The purpose of this is to be educating for both me and you and to inspire you to create your own mobile-friendly Linux apps.
Like the other KDE mobile apps I’m going to use QML/QtQuick and Kirigami. QML is the declarative UI language from the Qt project. Unlike the older QWidgets it is designed with (embedded) touch systems in mind and thus is ideal for mobile apps. Kirigami is a set of QtQuick components designed for creating convergent mobile/desktop apps.
Unlike other KDE projects I’m not going to use C++ for the business logic. Instead I’m going to use Python, which is now officially supported by Qt. Since my Python skills are fairly basic this will be a fun challenge for me. Therefore take everything I write with a grain of salt and feel free to point out anything that is wrong or can be improved.
This won’t be a 100% complete reference for developing for Plasma Mobile, but I’ll try to cover as many different aspects as fit into the concept of this app. I’ll also try to focus on one aspect/feature/goal per post. Also most of this will not be specific to Plasma Mobile but will work on any desktop or mobile Linux.
So lets get started 🙂
Part 0: Basic application
Before getting started we need to install a few things. First of all we need Python (obviously) and Qt for Python. Qt for Python was formerly known as PySide2. You can install it via ‘pip install pyside2’. Next there is Kirigami. On Ubuntu you can install it via ‘sudo apt install qml-module-org-kde-kirigami2’.
After that we can start coding. The following main.py file is creating an app and loading the UI from a .qml file. The exact details are not too important at this point.
from PySide2.QtGui import QGuiApplication
from PySide2.QtQml import QQmlApplicationEngine
if __name__ == "__main__":
app = QGuiApplication()
engine = QQmlApplicationEngine()
context = engine.rootContext()
if len(engine.rootObjects()) == 0:
Next we need to define our UI in a QML file. To keep things organized we are going to put our QML files in a qml/ subfolder. Our first main.qml is rather simple
width and height are a bit arbitrary since the window will always be maximized on the phone, but this way we get a somewhat realistic window on the desktop. Executing the python file should result in something like this
In the next post we are going to fill this window with more life using QtQuick and Kirigami components. Stay tuned 🙂