Category: Android

KDE is All About the Apps, an Akademy 2021 recap

7 August 2021 / apol / 2 Comments

Besides the talks, something very important about Akademy is the meetings you get to have with the different people working across KDE products. Our community work can fall into small groups, it’s in this occasions when we get to share and collaborate that we have that opportunity to make a big difference, at large.

Today I would like to sum up a bit the discussions we had among the different binary curation fronts. We had several of them, namely Linux, Plasma Mobile, Android, Windows, Mac and Automation.

You can take a look at the notes we took on the different meetings in the backlog of the goal’s matrix channel.

Something I find that is especially relevant here is to see the similarities we have across the board as it brings the opportunity to create ever better solutions than the work we’d manage to do separately. In this case, we have a repeating workflow across that consists of: building, testing, publishing and updating.

One obvious topic that was discussed in every single meeting is integrated tooling to actually build the applications. We already have certain infrastructure to do this already for most platforms in https://binary-factory.kde.org, but we are not entirely happy about it. So much so that we had a separate meeting together with sysadmin to see what we could do to improve it. They did mention that we are moving from Jenkins to GitLab CI which we expect to take this part of the process to the next level. If you have experience with DevOps and GitLab and would like to help, don’t hesitate to reach out to our sysadmins team!

Another part that was also discussed was Quality Assurance (QA). Is there practical ways to deploy a system that can help us there? openQA was floated several times as a solution, nobody seems to be very experienced there, also it’s unclear to us how that would work on other platforms as well. Again, feel free to reach out if you have experience and some time to spare. 🙂

The next step we always need to take is publishing. This is a topic that we have rather well solved on Linux through AppStream but less so on others. But in the end we always want the same descriptions, translations, icons everywhere. We have been trying to leverage it by converting these files into the formats other platforms use. It’s still to be seen if others will make it possible as well. Beyond the metadata, seeing to have applications updatable semi-automatically would be ideal and it is what we are aiming for, so when there’s big releases, we don’t need to have someone updating every binary one by one.

Streamlining this process can only make it more pleasant to work on our apps and making sure they reach everyone who need them. If you care about people using them, if you care to improve any of the apps, don’t hesitate to join the goal and talk to us.

https://kde.org/goals

KDE on Android: CI, CD & SDK

22 June 2018 / apol / 1 Comment

I guess we all agree that one of the biggest stoppers to get a contribution out is the ability to get the system ready to start working on the contribution. Today I want to talk a bit about generating Android binaries from our machine.

In the KDE Edu sprint we had the blatant realisation that it’s very frustrating to keep pushing the project while not being swift at delivering fresh packages of our applications in different systems. We looked into windows, flatpak, snap and, personally, I looked into Android once again.

Nowadays, KDE developers develop the applications on their systems and then create the binaries on their systems as well. Usually it’s a team effort where possibly just one person in the team will be familiar with Android and have the development combo in place: Android SDK, Android NDK, Qt binaries and often several KDE Frameworks precompiled. Not fun and a fairly complex premise.

Let’s fix that.

Going back to the initial premise of delivering KDE Edu binaries, the first thing we need is a continuous distribution system for Android, much like we already had for binary-factory.kde.org.

Our applications will be bundling some KDE Frameworks, we need to know which work, to make sure they don’t break to some extent, much like what build.kde.org is already doing.
And last but not least, while at it, we need to create a system that makes it simple for developers to do the same that our automatic systems are doing.

Docker to the rescue

We needed a way to pull everything we will need into a system: SDK, NDK, Qt binaries, few build dependencies. For this we created the following image:
https://hub.docker.com/r/kdeorg/android-sdk/ (Source)

With this image one can create binaries for his application locally.

We have also deployed it in build.kde.org to build some KDE Frameworks. Note that we are lacking some dependencies on Android so our offer is limited in comparison to traditional GNU/Linux. Also we are not running tests, it’s something we could look into but I’m not yet sure how useful that would be.

I want to develop

Here you have a wiki that explains how to use the docker image to build your KDE application.

I want to test

I set up an F-Droid repository that offers the binaries listed in the binary-factory conveniently, so that when there is a new version we will get the update.

Future

All of this ties directly to the runtime integration I mentioned already in this blog post.

Discovering South America – Qt Con Brazil

13 September 2017 / apol / 0 Comments

Few weeks ago I attended QtCon Brasil, an event organised by Brazilian members in the KDE Community who wanted to have an outreach event to the local technology community about Qt and beyond. It was great.

It’s always refreshing to get out of your own circles to meet new people and hear what they are up to. For me, it was more notable than ever! Different culture, different people, different backgrounds, different hemisphere!

We had a variety of presentations. From the mandatory KDE Frameworks talk by Filipe:

Some PyQt experience by Eliakin

And a lot more, although I didn’t understand everything, given my limited knowledge of the language consists of mapping it to Spanish or Catalan.

We got to hear about many projects in the region doing really cool stuff with Qt. From drug research and development to Point of Sale devices.
Us in the Free Software world, we are not always exposed to a good deal of development happening right before us, with the same technologies. It is fundamental to keep having such events where we learn how people create software, even if it’s on close environments.

Myself, I got to present Kirigami. It’s a very important project for KDE and I was happy to introduce it to the audience. My impression is that the presentation was well received, I believe that such wider community sees the value in convergence and portability like we do. Starting to deliver applications useful in a variety of scenarios will bring new light to how we use our computing systems.

Here you can find my slides and the examples I used.

KDevelop runtimes: Docker and Flatpak integration

23 May 2017 / apol / 6 Comments

On my last blog post I discussed about how some assumptions such as the platform developed on can affect our development. We need to minimize it by empowering the developers with good tools so that they can develop properly. To that end, I introduced runtimes in our IDE to abstract platforms (much like on Gnome’s Builder or Qt Creator).

There are different platforms that we’ll be developing for and they need to be easily reachable when coding and testing. Both switching and interacting transparently with the different platforms.

To that end I implemented 4 approaches that integrate different runtimes:

Docker, allows you to develop directly against virtually any system. This is especially interesting because it enables to reproduce the environment our users are having: behavior on execution and project information (i.e. the imports are the ones from the target rather the ones on our local system). Docker is a wide-spread technology in the cloud, I hope many developers will see the value in integrating the deployed environment into the IDE while they are coding.
Flatpak, is a solution that targets specifically desktop Linux applications. We are talking about distributing bundled applications to users, there we have the opportunity to integrate the tooling specifically to that end: from fetching dependencies to testing on other devices (see videos below).
Android, as you know it’s something I’ve been pushing for years. Finally we are getting to a space where the IDE can help get some set up troubles out of the way.
The local host, i.e. what we have now.

And remember KDevelop is extensible. Do you want snapcraft?, vagrant?, mock? Contributions are very welcome!

If there’s something better than a list of technologies and buzzwords, that’s videos. Let’s see why this could change how you develop your software.

One development, any platform

We get to develop an application and switch back and forth the target platform we are developing for.

Here I put together a short video that tests Blinken on different platforms:

Executes the application locally (ArchLinux)
Executes the application on OpenSUSE Tumbleweed through Docker
Executes the application on Neon development through Docker

One development, any device

Using the right SDK is not enough proof that the application will work as expected on every device, especially those our users will be using. Being able to easily send our application to another device to test and play around with is something I had needed for longtime. Especially important when we need to test different form factors or input devices.

In this video we can see how we can easily test an application locally and when it works just switch to Android and send to the device for proper test on the smaller touch screen.

Here we can see how we can just test an application by executing it remotely on another device. This is done by creating a bundle of the application, sending it to the device where we want to test it and executing it there.

Hassle-free contributions

You can’t deny it. You’ve wanted to fix things in the past, but you couldn’t be bothered with setting up the development environment. Both Flatpak and Docker offer the possibility to maintainers to distribute recipes to set up development platforms that can and should be integrated so that we can dedicate this 1 hour in the week-end to fixing that bug that’s been annoying us rather than reading a couple of wikis and – oh, well, never mind, gotta make dinner.

We can do this either by providing the flatpak-builder json manifest (disclaimer: the video is quite slow).

Or a Dockerfile.

You can try this today by building kdevelop git master branch, feedback is welcome. Or wait for KDevelop 5.2 later this year. 🙂

Happy hacking!

Sprinting KDE Connect

17 August 2015 / apol / 7 Comments

What will happen?

KDE Connect is nowadays on a sweet moment where many things can happen. This is an interesting moment to sprint, because it will allow all of us to work together on interesting features that can then be merged at once with greater impact.

The things that are the most important to me are:

The Plasma Phone port. See more below.
Improvements on the Plasma Desktop integration. Currently it’s a bit weird. It mostly works, but then it’s currently lacking any interaction with the remote devices. We should review what it does and what can we do to offer what the user actually needs.
Using the phone (or any other device) to transparently provide data to the desktop system. We have many interesting listed ideas. Use the phone to provide location, the phone’s microphone and camera, etc.
File system synchronization

What will I do?

One of the things I’ve been working on lately is a new KDE Connect client. Initially with the Plasma Phone in mind, this new application opens a new window of opportunity also on other platforms. First of all, it should be right away usable on Jolla (when they adopt a saner set of dependencies) and the Ubuntu Phone.

From our point of view, one of the biggest problems of KDE Connect is that we have a hard time to pivot over to other deskop-based platforms, mostly because our desktop approach so far is a plasmoid, which isn’t very portable. Having a standalone application will help as well to reach such platforms as well.

Another thing I’d like to work on further is KDE software integration on Android. Things should be set by now, but we need work to shape the path further. Things like setting up the KDE Frameworks 5 CI for Android for example will be a huge step forward. Also building some other application for Android, will help us get a better overview of the current state.

Support us!

All of this will happen in the next KDE Connect sprint within the Randa Meetings. If you like KDE Connect and wish it to bloom into the tool we’re all looking forward to, consider donating!

KDE Software on Android

12 June 2014 / apol / 19 Comments

Despite my involvement in KDE and free software operating systems, one of the features I’ve always loved from Qt is how we can use it to develop an application that can be used on any platform. Since I got my first /programmable/ phone, I’ve wanted to get my projects to work there, especially through all Nokia approaches to the issue, and I’ve managed to do so with relative success.

At some point last year I got to the conclusion that, if I wanted to remain somewhat sane, the best approach was to start focusing Android by caring about the CMake side of the issue and let QtQuick get into place, which is not in place yet, but admittedly in a much better state than a couples of years ago.

My KDE on Android approach is that any KDE project should be able to be built and bundled for Android from the sources, that is with an apk file as a result, without having to change the project sources: c++ or cmake.

I started working on this longtime ago on Qt4, but the fact that kdelibs was about to change and the poor direction of the port drove me away from bothering. Also if we want portable interfaces we want QtQuick Controls. I don’t think there’s much doubt there.

I restarted the project last November. I compiled a full Qt5 installation and started to get it to build, my intention was to use android.toolchain.cmake again, but I then decided that it would be better to create a new cmake toolchain file to have all the control I needed over how it’s being compiled. Some things need to be treated with special love like how executables are built and especially being able to create apks.

At the moment it seems to be working reasonably well, I’ve been using KAlgebra as a test. I get to easily deploy the Analitza framework which is a dependency and then consume it from KAlgebra which bundles all dependencies into a nice publishable APK.

Enough back-story, let’s see how we’d build KAlgebra (or any traditional KDE project for that matter).

To get all the features going we need:
* Qt 5.4 built for Android (currently in dev branch)
* CMake 3.0
* Android NDK
* Android Development Kit
* the ToolChain file I created (still to find a proper place, can be found here)
* Extra-CMake-Modules
* The project’s source code, because the power is in the source!

Here’s an example on how to get it done [1], but that’s the expanded version. As an attempt not to scare you here I used a simplified version, by having a cmakeandroid macro defined, passing cmake all the needed information.
mkdir build-analitza build-kalgebra cd build-analitza && cmakeandroid ~/src/analitza && make && make install cd build-kalgebra && cmakeandroid ~/src/kalgebra -DQTANDROID_EXPORTED_TARGET=kalgebramobile && make && make create-apk-kalgebramobile

Which I think it’s readable enough.

To conclude, we are able to consider Android as a candidate for KDE projects to adopt. There’s much more to do both on KDE, Qt and cmake sides, but we can get to discuss it when you’ve ported your application.

For the moment, I’d like to know if there’s any application that is interested in being built for Android, I’d like to give it a try, especially if it’s already been ported to QtQuick and Qt5/KF5.
Furthermore, in case anybody is interested, I’ll open a wiki page with this information, in case anybody wants to use it, for the moment my cmake toolchain and manifest can be found here:
http://quickgit.kde.org/?p=scratch%2Fapol%2Fkalgebraandroid.git

KDE SDK Next, how will we develop in a year?

19 March 2014 / apol / 6 Comments

Since the beginning of my involvement in KDE and, more specifically, my involvement with KDevelop, many people have come to me and said that what we “actually need” is an SDK. So far, I never gave this much thought. Especially given that for me, the SDK was the system I’m running on and, by extension, the packaging system of my GNU/Linux distribution.

After all this time and given one of KDE Frameworks goals is to broaden our portability, I started wondering about the subject again. Some of the pieces are starting to come together already, but I still think we need to actually glue them together in a clear and pragmatic approach.

Premise: we want to build an SDK on top of the tools we generally use:
CMake, Qt, KDE Frameworks 5, Plasma, QML and C++.

For starters, we have two different major scopes: Integration with Plasma and Cross-platform facilities.

KDE Applications should be as distributable and portable as possible. On the other hand, we should be providing the tools to specifically integrate to the Plasma Workspaces.

Applications have different use-cases than the Plasma Workspaces. While applications need to be as easily distributable as possible, Plasma will want to have as much control on the system as needed to work accurately. Therefore, we want applications interacting with Qt5+KF5 and integrating through Qt abstractions, while Plasma will want to interact random components in the system regardless without fear.

What I propose:

Figure out which frameworks are portable and which are Plasma Platform integration frameworks. (e.g. KDED modules, KNotifications, Solid: are they portable? do we want to support the different platforms?)
Figure out what do we mean by supported platform (both in the case of Plasma and Applications).

Once we get there, we will be able to think about developers and:

Offer a sensible set of tools to support the development and ease testing.
Figure out a packaging plan for the libraries and tools for developers, so they can start using them for their development.
Figure out a deployment plan for the frameworks on the different platforms, so that deployed applications know how to rely on the needed dependencies.

So this are mostly thoughts, I would like to know if you’d be interested in the project. I think it makes a lot of sense to figure this out and then gather this year’s Randa meeting to make sure we’re coming up with a coherent next development platform.

KAlgebra on Android

24 April 2012 / apol / 10 Comments

Since I started blogging I’ve talked many times about KAlgebra. Usually it’s not to display it’s awesome features but to discuss its portability. I’ve always considered that it’s important for KDE not to lock down its applications to a platform. That’s why I’ve put my efforts into ensuring KAlgebra will work properly on different platforms so far, like the N9 and Plasma Active.

— TL;DR: you can jump to the video 🙂 —

I think we’ve done a great job so far. It hasn’t been easy and we are not there yet, but I think that being able to do things like this is an awesome opportunity for projects like KDE Edu where we want to target the widest audience possible.

Android offers this, a widespread audience where we will be able to put our things. That’s why I put my interest in it, anyway.

Regarding the actual implementation, it’s far from perfect. It’s using KAlgebra Mobile, which has different backends. I created a new one that doesn’t require any components present. QtQuick components are lacking for Android at the moment, so I came up with this UI that besides not being properly integrated it works good enough and keeps me from frustration. Things are looking good on that regard, apparently I’m not the only one needing those, so I hope we’ll get some proper UX eventually.

A lot is left to be done still: Integration with the system, integration in the Market, etc. Ideas welcome.

Oh, and last but not least, big thank you for Marijn Kruisselbrink who put up with my questions and opened the path by adapting kdelibs.

And now, the video.

Almost forgot, if anybody wants to try it, you can download the installer here. Remember, it eats easter bunnies.