FreeSoftware to the fullest!

Category: KDE (Page 1 of 11)

KDE is All About the Apps, an Akademy 2021 recap

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.

All About the Apps

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

What should the FOSS desktop systems feel like?

It’s always tempting to look outside at what people say about what you create. Beyond KDE’s community, the Linux community is diverse and, more noticeably, surrounded with loud voices who observe what we create and comment on it. This is a good thing, it means that we are making relevant things and that people care. It also means that there needs to be a shared understanding of what is at stake.

It’s a bit of a meme how any change breaks your workflow and, while there is a certain amount of truth about it, it might pose a challenge. In this blog post I’d like to explain some aspects of what it looks like from the creator point of view.

Workflow

I started thinking about how to have this discussion more in the open after having seen certain reactions to KDE Neon’s offline updates announcement.

Before proceeding, let me offer you some context on the offline updates front. We have allowed our desktops to roll updates at runtime since forever. That doesn’t mean it has always worked for everyone. There are certain corner cases that would choke an application or maybe even the Desktop Environment. Since it’s not fatal we’d let it pass. I only started looking into offline updates more closely when I saw that the PinePhone KDE edition (or rather the dev image we were running to develop it) would fail consistently every time as we updated due to changes internal within KWin.

Neon Offline updating

To have this discussion I’ll summon another meme of the Linux lands: “The year of the Linux Desktop“. It’s been a around for a while since, it vastly predates my involvement in free software but it seems to still be a thing. We have seen Linux being adopted in many spaces but it’s seemingly never been enough to silence the dreamers among us. Now allow me to be a bit blunt.

I’m not sure if that year will ever happen. Or it will be 2054 or 2022. Now, I’m sure of one thing: The day where billions (as in 10^9) of people wake up and start their work day, it won’t be the case that the first thing they do is to open a terminal and run sudo apt update, sudo pacman -Syu, sudo zypper dup or sudo dnf upgrade. Users will need to run a system where dependency problems are never an issue, where they can install applications easily and where they can’t break their systems.

When I, and I think most of us in KDE, put together a feature, it’s towards making it possible for the world to adopt Free Software. We need to have as a goal a future where people can use our systems. Our “Simple by default, powerful when needed” goes beyond “I can easily change to a dark widget theme”.

Now I understand we are not there yet. I understand that many of us have some habits that are hard to change. But when we tell the world that we expect the linux usage to go beyond the current user-base, you need to be open to things changing. Your personal systems should become more “unbreakable” even if you generally “break it” (as in taint the integrity) in small ways to make your life easier.

In the end, we the hackers, will always have ways to achieve what we need be it by using more DIY distros, using fancy tools or by patching the system call table and forcing an unexpected reboot.

My 2020 with KWin Wayland

Over the last few years and especially since the Wayland goal vote, the Plasma team, we have been focusing on having our Plasma Wayland experience work at least as good as our traditional Plasma X11 experience does. Today I’d like to wrap up my experience on this front for 2020.

Despite having been working on KDE and even Plasma projects for a long while, I’d never gotten much deep into working on KWin internally. I dipped my toes in it in 2019 when working on the key states feature (that plasmoid that says if caps lock is pressed or not, which we needed because the KDE Slimbook didn’t have an LED for the Caps Lock). Here I’ll discuss a bit how it evolved over time.

Features

Tablet support

It’s probably been my first big feature contribution to KWin. From 5.19 you’ve been able to use your tablets to draw things, all features should work fine and life should work. In the beginning, I was mostly interested in getting the 2-in-1 tablet with a pen work, hence implementing this one first.
The rest of the spec implementation is pending review here and hopefully should make it into 5.21: https://invent.kde.org/plasma/kwin/-/merge_requests/559

Screen casting support

This is something I’ve worked on mostly with my Blue Systems hat on, but still is something very important for our daily usage of Wayland, especially nowadays where working remotely is more important than ever and sharing our screens and windows is something that we need to do on a daily basis.

KWin used to support already sharing screens, or rather xdg-desktop-portal-kde could, now we centralised the implementation in KWin and made sure it’s as performant as possible. It was admittedly rather complex to put together, but allowed me to understand how the system works and helped me have a better insight of the architecture.

Input Methods

Plasma Mobile is becoming a palpable reality and input is very important on any touch device. In Plasma Mobile we’d been relying on having Qt’s embedded virtual keyboard since the beginning and while it worked reasonably well, we needed to make it possible for us to offer more and better solutions. This time, we implemented the unstable input-method protocol which allowed us to use keyboards implemented in a separate process, hence making it possible to integrate the Maliit keyboard transparent, as well as the weston keyboard if minimalism is your thing.

Maliit keyboard

This, of course, opens the possibility of much more development on top in terms of other better virtual keyboards, improving the current ones or the integration of more esoteric kinds of input methods (e.g. ibus, fcitx, emoji keyboard or even spell checkers and the likes).

Developing comfortably

Something that was clear to me as soon as the Wayland Goal was shaping up was that we had to find ways to free ourselves a bit from the ABI limitations. From the beginning, Wayland interfaces started to be developed in KWayland under KDE Frameworks 5. This meant that server-side implementations had to stay backwards compatible to certain versions of KF5 and that we couldn’t do certain things. We moved KWayland Server components into a separate component here, that is released with Plasma and we can develop as we see fit: https://invent.kde.org/plasma/kwayland-server/. Note that KWayland Client classes stay there where they always were.

This has allowed us in turn to adopt the usage of qtwaylandscanner, which is a tool that generates certain boilerplate C++ code for us from the xml spec, allowing us to focus on the parts we care about in the implementation. This makes Wayland protocol implementation a bit more straightforward while removing some code. You can see the MRs Adrien and Vlad made doing this if you’re curious about the changes it conveys. Our first protocol implementation to use qtwaylandscanner was the keystate protocol I mentioned earlier.

Talks

As it’s important to explain what we do so people are aware of it, I decided to take some time this year to explain the different aspects of our Wayland initiative and overall why Wayland makes sense. You can see it explained here, I wouldn’t recommend you to look at them all, but it could be useful for you to look at the one that fits your perspective better.

KWin and Wayland

Wayland for Product creators

Wayland for App Developers

Plasma Wayland: donde estamos y como ayudar (in Spanish)

Future

I know there’s a lot of really exciting stuff coming up from the team. If you’re interested, stay tuned. We will be having a sprint early January to discuss different topics from major roadblocks to a light and comfortable experience.

Consider joining us either at the sprint or at the Wayland goal forums and work with us towards a better experience using Free Software and Plasma.

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!

Plasma Mobile, 2020 is starting strong

Earlier this month I attended FOSDEM and the Plasma Mobile Sprint right after. Both of these events were especially important for our mobile venture. First, seeing how people are asking us to provide a good experience also in their pockets, then seeing how many people and energy is being put into making it happen.

Now what’s to coming from my end?

Better Wayland integration: keyboard

This was what I spent most of my time during the sprint. Now it was a bumpy one for me, since I got a bit of a flu and I wasn’t on my best shape. Still, it got me to produce this patch which implements zwp_input_method_context_v1 into KWin. Yes, there’re discussions of iterating the protocol, but as is, it already allows us to adopt Maliit, integrate some of ibus and in the end, exposing some very interesting features so one can care for text input without hacking them right into KWin.

Optimal EGL interfaces

Something else that was (made) clear to me that needed implementing was EGL_KHR_partial_update. This one is especially important specifically for the Pine Phone, but I’d expect other drivers to implement such an interface over time. It allows us to tell the driver which parts of the screen have changed, which is expected to in turn offer better responsiveness when rendering, since there’re some textures that won’t need to be fiddled with, when using a graphics card that uses tiled rendering.

For the curious, you can find the patch now here.

More Android

Having Android support for our applications has been undoubtedly useful for Plasma Mobile. We have a bunch of Free Software applications being developed on Android such as: Itinerary, Kaidan, Kirogi or Kongress. All these applications will be handy the day Plasma Mobile is in all our pockets. Until then, we can develop them for Android and get them used by the any of the millions of people who nowadays use the system, including most of us.

Now this is a delicate time since Qt 5.14 introduced a bunch of changes that made us have to adapt what we had, but now we are there and we’ll soon be able to start offering you all our applications using Qt 5.14 and newer stable versions as well. Volker explained it very well here.

I hope you’re all excited like I am to see Free Software reach our pockets. Plus, I’m also glad about how getting it in the pockets improve the experience overall: all the new apps will be useful when we are on our Desktops. All the Wayland improvements and optimizations will make our systems more useful and responsive.

What a time to be a free software hacker! 🙂

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/

Meet KDE in València

During the next days, we’ll be having several sprints in València.

First we’ll be having the KDE e.V. Board on Monday and Tuesday then we’ll be having two big sprints:

  • Plasma, where we’ll be planning and working on the features for the next year (or more!)
  • Usability & Productivity goal’s that will look into different applications and components in KDE that need attention to work properly and improve them.

If you are around and you’d like to meet the different groups, we’ll be having open dinners so you can join and ask us anything.

  • The Board dinner will be next Monday 17th June at 20:30.
  • The Plasma & Usability dinner will be next Saturday 22nd June at 20:30.

Send me an e-mail to aleixpol@kde.org saying when you’d like to come.
The location will be decided depending on the amount of people who ends up coming.

Last but not least, big thanks to Slimbook for hosting us for this sprint! 🙂

Easily building and testing KDE applications into a separate prefix

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!

« Older posts

© 2021 TheBlindCow

Theme by Anders NorenUp ↑