FreeSoftware to the fullest!

Category: GNU/Linux (Page 1 of 2)

Developing KDE as Products

One thing that is special about KDE software is how it can mean different things depending on your perspective. This is very powerful from a technical perspective, but can make our work harder when we want to convey what our piece of software does and how it will affect its users’ life. How do we optimize our product development towards user acquisition and support?

At Akademy, I discussed shedding some light on the blurry lines that sometimes define our products, and did so based around the Marketing-Mix I was taught at university (so no, I’m not an expert!). I presented it first at a talk, then we had a subsequent BoF session to discuss it and see how it mapped to some projects (we did Plasma and Okular, as a test) to get acquainted with the concept.

What will evolving this process look like? For starters, having some people more knowledgeable on the topic involved. Some already told me they are interested in helping. Big thanks 😊. And then, let’s get our hands dirty.

Maybe more hands-on for each product? I can see ourselves sitting down and discussing how the status quo contrasts with the picture the Marketing Mix would suggest for our products. I have done it for some, and I have the feeling that there is a lot of unexplored potential.

Is your work available on the places you would like it available? Is the product you have in mind the same you’re promoting?

Now are you interested in helping with this process? Would you like to see how we can polish the product you are maintaining? Is there a product in KDE that you think could use this kind of help? Comment down below or send me an e-mail at aleixpol@kde.org and I’ll see to finding some time to sit down and working on it.

Developing KWin Wayland

On the last few weeks I’ve been looking at KWin more closely than in the past. It’s definitely a special beast within KDE and I figured it could be useful to give some hints on how to develop and test it.

When developing something, first step is always to compile and get the code installed and usable. It’s especially delicate because when we mess up our system becomes quite unusable so it needs to be done with care. To prevent major damage, we can probably try installing it into a separate prefix (See this blog post, change kate for kwin).
Second step is to make sure that modifying the code will modify the behaviour you perceive. This is what we’ll focus on in this piece.

Bear in mind most of the things I’m saying here are possibly obvious and not news, but it’s still good to have it written in case you feel like building on this (not fun to come up with) experience.

Testing KWin, Nested

That’s the first that we’ll probably try. It’s simple: we run a kwin_wayland instance within our system, it shows a window with whatever we’re running inside. I find it useful to run a konsole inside to trigger other applications. It’s also possible to point processes run elsewhere to that socket too but I haven’t really come across the necessity.

We’ll run something like:
kwin_wayland --exit-with-session konsole

Or even:
kwin_wayland --exit-with-session "konsole -e kate"

In any case, a good old kwin_wayland --help. The --exit-with-session bit isn’t necessary but it makes it useful to easily close it.

One of the biggest advantages of using it like this is that it’s very easy to run through gdb (just prefix with gdb --args kwin_wayland...), so still something to remember.
This works, but it’s usefulness is limited because important parts won’t be run: input, which will come from the actual session rather than from the kernel; and drm, which will go into the virtual session than to the kernel for the same reason.

TL;DR: if you’re modifying KWin to talk to the kernel, this won’t work.

Testing KWin, standalone

Next thing to try is to run it separately. Now you’ll want to move to a tty (e.g. ctrl+alt+F2) and run the same command as earlier. Now we’ll run the same code as above. Instead of getting a window now we get it full screen and using DRM and libinput straight from the source. *yah!*

It’s still quite uncomfortable though: the output will be going to the tty which we can’t see because we have kwin on top and if it crashes we’re at a loss. Also running it with gdb is a pain because we can’t interact with it.

That’s why for this I’d recommend to ssh into the system from another one. I’ve found the sweet spot there to use a combination of ssh and tmux (screen should work as well, there’s tons of doc on how to use either online). Using ssh we find 2 main problems: if the connection breaks the whole set up is left in a weird situation and from ssh we don’t really access the tty.

If you don’t have 2 computers available, you can ssh from a phone as well, should be good enough, especially if you can get an external keyboard, although a nice screen is always useful.

So what we’ll do is:

  • Make sure our system has sshd running, check the IP
  • host$ tmux
  • othercomputer$ ssh $IP
  • othercomputer$ tmux a

And then we’re seeing the same on both, and we can run kwin_wayland on either and everything will work perfectly: we’ll see debugs we may be adding, we’ll get to kill it with Ctrl+C if we please, we can run gdb, add breakpoints. Anything. Full fun.

Problem being it’s just KWin and there’s more to life than a black screen with a dancing window.

Testing a full Plasma Session

To start Plasma Wayland from a tty we run startplasma-wayland. This gives us a complete Plasma instance on Wayland. The same as if we were running it from a display manager like SDDM. Running it from another system tmux still has advantages, like we’ll get to see the debug output. Starting a kwin_wayland session under gdb is way beyond this blog post and barely useful considering the standalone approach I mentioned earlier. What we can do though is to attach to the running gdb.

From the other system (on tmux or not, although I find it useful to just put it in another tab) we can run sudo gdb --pid `pidof kwin_wayland` and it will attach. Then you can add your gdb business: breakpoints, make it crash, look at backtraces, print variables or just stare at it hoping things get fixed automatically.

tmux with logs

Other

There’re other things that have proved useful to me like running it on valgrind or with a custom mesa build + modified LD_LIBRARY_PATHS. This works as with any other project, except it doesn’t by default.

KWin has a safety system set in place that prevents running it on emulators like valgrind and prevents LD_LIBRARY_PATHS from being tampered with. Which is great in general but prevents us to do certain things.

To address this in our build, we can comment out the code in kwin/CMakeLists.txt where ${SETCAP_EXECUTABLE} is called on kwin_wayland. You’ll need to make sure kwin_wayland is recreated, so remember to host$ rm bin/kwin_wayland. This bit here made me waste a fair amount of hours mind you, so it’s worth keeping in mind.

It’s also worth remembering there’s a ton of debugging tools that can be used. Here’s some:

  • WAYLAND_DEBUG=1 environment variable to see how the wayland protocols are flowing.
  • gpuvis, useful to get an idea of how rendering is performing.

Also note that all of this applies for Plasma Mobile as well, where it’s also useful for applications as well, where it’s most convenient since you get a proper keyboard and screen to look at debug output and gdb traces.

Hope this was any useful to you.

Happy hacking, stay safe!

Learning about our users

In a product like Plasma, knowing the kind of things our existing users care about and use sheds light on what needs polishing or improving. At the moment, the input we have is either the one from the loudest most involved people or outright bug reports, which lead to a confirmation bias.

What do our users like about Plasma? On which hardware do people use Plasma? Are we testing Plasma on the same kind of hardware Plasma is being used for?

Some time ago, Volker Krause started up the KUserFeedback framework with two main features. First, allowing to send information about application’s usage depending on certain users’ preferences and include mechanisms to ask users for feedback explicitly. This has been deployed into several products already, like GammaRay and Qt Creator, but we never adopted it in KDE software.

The first step has been to allow our users to tune how much information Plasma products should be telling KDE about the systems they run on.

This mechanism is only integrated into Plasma and Discover right now, but I’d like to extend this to others like System Settings and KWin in the future too.

Privacy

We very well understand how this is related to privacy. As you can see, we have been careful about only requesting information that is important for improving the software, and we are doing so while making sure this information is as unidentifiable and anonymous as possible.

In the end, I’d say we all want to see Free Software which is respectful of its users and that responds to people rather than the few of us working from a dark (or bright!) office.

In case you have any doubts, you can see KDE’s Applications Privacy Policy and specifically the Telemetry Policy.

Plasma 5.18

This will be coming in really soon in the next Plasma release early next February 2020. This is all opt-in, you will have to enable it. And please do so, let it be another way how you get to contribute to Free Software. 🙂

If you can’t find the module, please tell your distribution. The feature is very new and if the KUserFeedback framework isn’t present it won’t be built.

Join the Linux App Summit in Barcelona!

As many of you will know we, at KDE and together with GNOME, are organising the Linux App Summit (LAS for short). It will be in Barcelona between the 12th and 15th November.

For those of you who haven’t heard of LAS:

The Linux App Summit is designed to accelerate the growth of the Linux application ecosystem by bringing together everyone involved in creating a great Linux application user experience.

Participate!

If you would like to talk about what you have been working on, you still can send us your talk. We extended our call for papers to the next week-end. You can learn more about it here: https://linuxappsummit.org/cfp/

Come!

Registration is now open, and it’s open to everyone! Meet leading experts in Linux and have interesting discussions about the future together.

You can register here: https://events.linuxappsummit.org/

Reaching out

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!

Qt Contributor Summit 2018

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

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

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

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.

A laptop by KDE

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.

« Older posts

© 2020 TheBlindCow

Theme by Anders NorenUp ↑