TheBlindCow

FreeSoftware to the fullest!

Category: PlasmaPhone

KDevelop runtimes: Docker and Flatpak integration

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:

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

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!

Support KDE Sprints 2015!

© 2017 TheBlindCow

Theme by Anders NorenUp ↑