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!