TheBlindCow

FreeSoftware to the fullest!

Author: apol (Page 2 of 14)

Reaching out

24 December 2018 / / 3 Comments

One of the activities that we have been promoting is joining conferences on topics that we’re interested in. Last September I joined two of them: the Libre Application Summit and EduCode.

Reaching out within the community

In the Linux community we’re portrayed as tribalistic quite often, there’s good reasons of that. Having been part of KDE day to day for years, I also must say that it’s clearly been blown out of proportion. There’s collaboration all over the place and we should celebrate when it happens. Sitting together and sharing visions is useful, which we did in the last Libre Application Summit in Denver.

Among others, we learned about Flatpak’s internals, elementary’s software distribution approach, fancy new ways of distributing linux operating systems and how some free software we have available on linux can be used by graphics designers and how they reach them. Of course, there were the KDE bits that Albert and I brought.

I would say that the ultimate goal for all this wasn’t exclusively to learn about it but to actually sit together and talk. Which we did and I’m looking forward to do so again next year, hopefully with the rest of communities working on desktop, applications and distribution.

Reaching out to users

It’s a completely different story, for sure, but it needs doing too. In this occasion we joined a conference full of Belgian and French teachers who are interested both in Free Software and having the best educational tools available for their students.

This is especially important for two main reasons: we get to explain to some of our most prominent stakeholders what our software does and why it’s great but also we get to see how they react and what they miss. Caring and listening to users is crucial to the health of any project.

I was tempted to upload another picture of the crew up there (Adriaan, Paul and myself) but it’s rather unflattering to say the least, so we’ll stick with Paul looking all smart. 🙂

Of course, these were only the conferences I attended the last few months, but there’s been several other conferences where KDE has joined, join the planet KDE to know more!

Easily building and testing KDE applications into a separate prefix

29 June 2018 / / 2 Comments

When developing your projects you will often need to install them somewhere safe. On my system I have a prefix full build of all Qt, KDE software, but this doesn’t work when we just want to work on an application or want to test a build in someone else’s system.

Installing to /usr doesn’t feel right, /usr/local isn’t that much helpful either, so what I usually do is to create a sub-directory in /opt (e.g. /opt/discover, /opt/kalgebra), then it was a matter of having the session point at the right place. This is why I submitted a small change in ECM that generates a prefix.sh that sets the right environment variables.
This was merged a while ago, so it should be part of any distribution by now.

This is what the workflow ends up being. First we fetch and build the software we want, as usual:

$ git clone kde:kate
$ mkdir build-kate
$ cd build-kate
$ cmake -DCMAKE_INSTALL_PREFIX=/opt/kate ../kate
$ make
$ make install

Then to run it, we just need to do the following:

$ source prefix.sh
$ kate

And we’ll get our own kate, with the modifications we made.

Hope this helps!

Qt Contributor Summit 2018

22 June 2018 / / 3 Comments

I guess you’ll have seen Albert’s blog post about the Qt Contributor Summit, if not do it.

I thought it would be interesting to recap a bit. As he put it, most discussions revolved around how to iterate every part of Qt into Qt 6. It’s exciting, a little bit scary but exciting.

One bit especially interesting is the graphics stack. Back in Qt 5.0, Qt took the liberty of limiting the graphics stack to OpenGL, but the world has changed since: On Windows the only proper stack is Direct3D 12, Apple introduced Metal and recently deprecated OpenGL and Vulkan is coming rather strong. It looks like embracing these systems transparently will be one of the most exciting tasks to achieve. From a KDE & Plasma perspective I don’t think this is scary, OpenGL is here to stay on Linux. We will get a Framework based on a more flexible base and we can continue pushing Plasma, Wayland, Plasma Mobile with confidence that the world won’t be crumbling. And with a bit of luck, if we want some parts to use Vulkan, we’ll have it properly abstracted already.

Furthermore, here’s some of the re-caps some people (mainly Thiago ^^’) uploaded after the sessions:

I think it was a great conference, thanks to Tero and The Qt Company for putting it together. And thanks to the sponsors for making it possible. 🙂

See you all again, Qt-ies!

KDE on Android: CI, CD & SDK

22 June 2018 / / 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.

Docker as an SDK for ARM distributions

18 December 2017 / / 2 Comments

Lately I found myself working on an ARM64 (aka aarch64) based system which in turn I don’t own. So I needed to get a system to build and test things on.

How?

First of all, you need to have qemu static builds installed. For example, for ArchLinux you need to get them from AUR:
$ yaourt -S qemu qemu-user-static binfmt-support

And then enable the aarch64
# update-binfmts --enable qemu-aarch64

$ docker run -ti --rm -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static apol/test bash

X11

Once set up, it can be used as any regular docker image. For example passing -e DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix will give us access to X11, allowing to run apps:
$ docker run -ti --rm -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -e DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix apol/test bash

One possibly wants to use Xephyr to test some stuff, probably on the safer side.

Similarly, you’ll get to use gdb or any tooling you need and is available for the architecture.

KDevelop

You get to code against your project against the platform you need by passing the extra required arguments, then most features discussed here apply.

Beyond…

Granted it will work rather slow, as it’s emulation, but given the alternative is not being able to work at all, I’m happy.

Note that most of this applies for any architecture, replacing aarch64 for any architecture supported by qemu (and your distro of choice): You can check /usr/bin/qemu-*-static.

Tracking a QObject’s life

28 November 2017 / / 3 Comments

Why?

One of the interesting things about QML is that it leverages OOP property semantics of QObject to drive its declarative workflow.

How?

We attach into any QObject the developer requests and monitor it (and optionally all it’s children).

To gather the information we need, we will collect information for every property and connect to the property’s notification signal to see when it changes.

What?

This is the repository:https://phabricator.kde.org/source/kobjecttracking/.

This allows us to see:

  • Spurious property change notifications
  • Property changing bursts (i.e. same property changing values repeatedly in a short amount of time)
  • How a change in a value can have an effect on other properties

At the moment we have two ways of inspecting an application:
On one hand we have warnings that allow us know specific things and even add breakpoints to the sore points. The warnings at the moment look like this:
repeated value ScrollView_QMLTYPE_43(0x5648c6d97b50) width QVariant(double, 320) 8 times
repeated value Kirigami::BasicTheme(0x5648c6986ac0) backgroundColor QVariant(QColor, QColor(ARGB 1, 0.988235, 0.988235, 0.988235)) 11 times

Additionally, we have a timeline view output from tracking. You can see an example of plasmashell run here.

Future

An idea would be to integrate automatically ModelTest, so if a QAbstractItemModel is found, a ModelTest instance is attached that makes sure the model is true to its promises.

Another thing that bothers me is that we are forced to compile it into the application. If we could make it possible to have processes attached or start the application somewhat automatically (like GammaRay does, wink-wink) we would ease the adoption of these tools.

What do you think? Do you think it’s useful?
Feedback very welcome.

Discovering South America – Qt Con Brazil

13 September 2017 / / 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.

Welcome

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:
Filipe talking about KDE Frameworks 5

Some PyQt experience by Eliakin
Eliakin discussing PyQt

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.

Kirigami at QtCon

A laptop by KDE

10 August 2017 / / 4 Comments

Earlier this year we announced a joint venture between KDE and Slimbook that we named the KDE Slimbook.

Last Akademy we had the opportunity to meet the Slimbook team and discuss its purpose and future. I’m quite happy about the discussions, here’s my feedback.

KDE Slimbook

Why?

Before talking about future stuff, let’s set the context.

Personally, this has been a long-standing pet-peeve of mine. We create software solutions for virtual hardware specifications. We require our users to go the extra mile by replacing the manufacturer’s operating system, often with some annoyances because their hardware isn’t properly supported. This is not necessarily our fault, but most of us agree that we should improve this situation.

On the software side of things, while it’s our area of expertise, we are still far from being able to deliver the product we would like to give. Our ecosystem is still complex and our users have to take several decisions, some of dubious nature.

Hence, I started pushing for this project with some colleagues from KDE.

Where are we?

As discussed in the Akademy presentation, the project worked reasonably well. Devices were delivered and the KDE community does see value in the project.

We have reached a point where we understand the value of the initiative and understand the environment much better. We are happy with the results so far and we see room for improvement; both in the task we do to make a better device as well as in defining the product.

Future

I want to see the project moving forward and I will keep working towards better cohesion between hardware vendors and KDE. In the future, I would like to see the devices that we see available, especially when it comes to different use cases, and therefore form factors.

I don’t think it makes sense that we continue doing it just to do so. There is a good deal of hardware vendors that will offer devices with good setups. Most of them they will even offer you these laptops with KDE on them upon demand. If we put our effort in such projects, it needs to be because we are making something special.

Let’s not get ahead of ourselves. One step at a time. Let’s continue to provide good solutions by staying simple by default but powerful when needed.

Snap in Discover and the GNU/Linux Desktop

5 July 2017 / / 4 Comments

Last week I attended a sprint with the Snap team and some other members of the community. One of the things we looked into was the Software Center story at depth so I thought it’s a good moment to give you an update.

Discover’s Snap Backend

Long due, some of you have already been using the testing version of it. During this sprint it was refactored to use the snapd-glib library that should simplify a bit the maintainership of this piece of software.
I’m aiming to having a stable snap back-end for Plasma 5.11.

AppStream

One of the reasons holding us back was the lack of AppStream support both in few spaces: getting proper information from the application, leveraging the appstream identifiers. This will allow snap software centers to have rich information ready for users to better choose their software.

My understanding is that the development of these features is well under way and should be available to us soon.

Desktop integration

One of the really cool things about Snap is how well it integrates with cloud/IoT stuff. While this makes it really powerful, us desktop users and developers have seen some things that will need tackling eventually. Things like styling, fonts, icons, etc. need to be properly represented in Snap and it’s good to see this coming together nicely.
These were all subjects that were discussed during the meeting, so do get your hopes high!

KDevelop runtimes: Docker and Flatpak integration

23 May 2017 / / 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:

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!

« Older posts Newer posts »

© 2024 TheBlindCow

Theme by Anders Noren — Up ↑