This month has been amongst the most intense of my FOSS journey I’d had in a while. We had both the Plasma sprint and the LinuxAppSummit (LAS).
You can follow what was done in the sprint at the manyblogpostsbyour teammates. Thank you all!
When it comes to LAS, you can look at most videos here. However, you’ll be missing out on the experience of joining it. Consider joining next year!
All in all, it gave me a nice feeling of realisation that we are on the right track at large. Plasma is getting lots of love by our devs, ensuring a continued stream of improvements to our UX. From a Plasma standpoint, we are slowly exploring the possibility of having add-ons with Flatpak. I find this an exciting development that can bring Plasma extensions to a next level, that wouldn’t be feasible without the work from many of the folks at LAS.
And all that to say that we are all fine, and healthy. Either Plasma or LAS, both are nice communities full of nice people pushing our ecosystem together towards new horizons that I’m sure we’ll all be happy to explore.
It’s no news that cool kids don’t blog anymore. So passé! That’s why Harald and I, we have started doing some mild streams where we discuss topics around our little FOSS perspective like KDE, Plasma, KDE Linux and the likes.
I’ve been announcing the next episodes in my Mastodon account as well as in the involved Matrix channels. There I try to announce the next episodes and when they’ll happen. It’s generally been on Sunday evenings.
We are total noobs about using Twitch and all that, don’t hesitate to suggest us how to do better.
As we have been doing yearly, a few weeks ago we had the 2024 edition of Linux App Summit (LAS). For those of you who don’t know, the Linux App Summit is a conference co-organised between KDE and GNOME among others where to bring together the different stakeholders of the linux ecosystem to make sure we have all the collaboration tools in place to have a great state of the art platform for the uses the world needs from us.
This year it was special in that since it became the Linux App Summit, we held it outside of Europe! We had LAS in Monterrey, the northernmost part of México in the ITESM (Instituto Tecnológico y de Estudios Superiores de Monterrey), a really nice campus and a beautiful venue.
Besides meeting people from other projects as I’d normally do in LAS, this year I had the added opportunity to meet the community the other side of the ocean. There certainly are good differences between how we organise FOSS communities Europe and there, it’s always useful to experience and iterate to ensure we are truly creating a community for everyone.
LAS ’25, Call for hosts
Are you considering bringing such communities to your home town? Please reach out, you can find some information how to do that here: https://linuxappsummit.org/bids/.
In my opinion, organising a conference is one of the best ways to bring FOSS talent to where you are. It’s often hard to find new ways to be part of what we do, this is a great one. I personally had the opportunity to do it in LAS’19 in Barcelona and it was a great experience.
LAS has the added value of being a melting pot of people from different communities so it’s a great opportunity to meet people that you might not crossed paths with before!
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.
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.
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.
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.
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. 🙂
In a few days (May 13th-14th) the KDE e.V. board will be having an in-person board meeting in Berlin.
We’d like to take this opportunity to meet and talk to other people in Berlin besides ourselves, so we’re organizing a dinner on Saturday 13th around 19:00 (location still undecided, suggestions accepted).
So if you are interested in talking about KDE, KDE e.V., Free Software, Open Source, or any other random talk and want to have a good time let me know that you’re coming as soon as possible, space is limited.
The world changes, and with it, we change too. For this new version of Kamoso we wanted to iterate what we’re presenting.
The Camera
Since we’re using GStreamer, we could take advantage of newer technology available there. Now we’re using camerabin for the video capture (in contrast to using v4l2src directly).
This will offer a better experience, with less tweaks on our side, that will definitely improve the end-user experience.
User Interaction
The whole application wasn’t rewritten, but all the UI was. We have a re-designed interface that integrates some really lean and meaningful animations and sorts the components so that we can get a simple, dialog-free UI.
Sharing
Sharing is probably the most important feature in Kamoso besides video capture, and we took special care of it. We adopted the new Purpose technology that is seeing its light for the first time with this Technology Preview. We want to make sure that we can offer the best solution by making sure it integrates properly on our UI and it can also be integrated on other parts of KDE. This way we’ll be able to come up with an adequate set of plugins and enjoy them all in community. For now, we have: KDE Connect, Imgur for images and YouTube for videos.
Where to find it?
I put together this little list, so everyone can find the tarballs and packages (on the distributions that managed to package it): https://userbase.kde.org/Kamoso/3.0#Alpha
We need you!
We need special help with:
Testing, on more cameras, more hardware.
Artwork, especially icons.
Coding, especially Purpose sharing plugins (Facebook? Twitter? ownCloud?)
But anything else is welcome, as always. Please get in touch!
I joined KDE to hack. I wanted to create new thriving technologies for the world, to create tools, to learn, and, in general, to add some pragmatics into my perception of technology.
The one thing I didn’t really expect to do is all the rest.
I starting actively contributing to KDE in 2007 and I started contributing to both KDE Edu and KDevelop almost at the same time, I’ve talked largely about this aspect already so I won’t expand. I want to explain the rest.
The Community
My first Akademy, in Glasgow. felt spectacular to me, I made good friends and I remember having very deep experiences. With Albert, Anne-Marie, Rafael, Alexander, I loved the feeling that working together we could do great things and also that I could learn a lot over here. Those who know me know that despite being quite an introvert I tend to start talking a lot when I get engaged, and I remember talking a lot over there.
Foreign country, people, language, nothing mattered, the only important thing was to learn and to hack. I remember partying lots and hacking lots just as well over there. I’m explaining this because there needs to be an explanation, why someone who just wanted to hack ended up founding KDE Spain or joining the KDE eV board?
KDE Spain
Later in 2007 we organized the Akademy-es in Zaragoza. Different setting, different people and different perspective. There you did’t talk to people who want to work with you, they wanted to be convinced about KDE, about Free Softwre. I enjoyed it, it was healthy to put in perspective everything I was doing. Thinking about how to motivate others helps a lot to redirect oneself, to keep with the feet on the ground.
Later on, we decided to start KDE Spain, which was basically the intention to keep doing that in the future. Reaching out to local people, those who you won’t find on our mailing lists, at least not before you get there. KDE Spain has been to the day one of the projects I’ve invested myself the most.
KDE eV
I joined the KDE eV late in 2008. I was by then convinced that without infrastructure all good to be done in the project is in vain. We’ve all had this feeling when you see another project offering something that you have had for years unnoticed. It requires work, many pieces coming together.
Community software development (or any development for that matter) is much more complex than one would want. It needs organization and expertise in crafts one wouldn’t think before. That is one of the main reasons to push for KDE to me: having people from different fields coming together to make wonderful things happen. (Community as a Service, CaaS. Have we coined that yet?)
Barcelona Free Software
Life is all about balance. From generic to specific, from big to flexible. Life artifices made it so that my city, Barcelona, has become a focus of the KDE development and we had to take advantage of the opportunity. This time we went full local, we started to gather many people knowledgeable about KDE around and instead of creating yet another KDE thing, we created a group concerning Free Software in Barcelona.
With the huge help of Martín, we’ve built an open group to meet and discuss about Free Software in a nice and relaxed setting. It was a piece I always missed in the puzzle.
How to make the world use Free Software?
For example, people around me. Are we offering what they need? What do they use?
How come I don’t even know them? What do they create?
Muon has been a project that I’ve been very eager to port and iterate for a longtime. I’m happy with the 2.0 series, lots of changes were made and it has served us well. More importantly though, we have a solid technology to keep pushing our work on.
Porting
Now the first change has been the port to Qt5 and KF5 and adoption of QtQuick 2. This has been one of the few projects that have suffered from it, especially because we did a couple of hacks so that Muon Discover would integrate with the rest of applications’ look and feel. In any case, it’s sorted out now, we adopted the new QtQuick Controls and it works quite good, only problem being the usage of QQuickWidget, but that will be solved eventually, when we have everything we need in place to take the next step towards better integration between KXmlGui and QtQuick.
What to expect?
The most important news is that it will be as good and fresh as it used to be, integrated with the newer look and feel themes, capable of offering different sorts of data, such as applications, wallpapers and plasmoids.
Furthermore, some new features will be introduced with the forthcoming Muon 3.0 that will change how we integrate Muon on our systems. First of all, Appstream is being adopted for good. Now it will be possible to get a useful PackageKit backend, which has been adopted recently.
Additionally, for the ArchLinux fans, I did some fixing on the PackageKit libalpm backend so now it can be used again. 😀 Still, work on the Appstream set up is needed and help is very welcome.
Since I wanted to use a good PackageKit reference implementation, I looked into Fedora. I’ve been trying to get it working, but haven’t succeeded that much yet. I expected Appstream to be a first class citizen there, and things keep falling apart. We’ll have to work more in this area.
Kubuntu will remain using QApt for now. It seems to be working properly and there’s no intentions to change. Debian has also been ported to use use the same backend, we are pending though on some decisions to be taken with regards of metadata sources, that is, Appstream again.
**shrug** Looks like we’ll have to give a good push to Appstream!
Future
I would like to see different Plasma-oriented distributions embracing Muon as a resource management front-end. So far, resource management hasn’t been part of our user experience, with the exception of KNewStuff.
Additionally, there’s a forum thread where a new graphical design is being worked on so it doesn’t look all that clunky (especially managing to make QtQuick Controls applications look good).
All this is already available on our Git repositories. A final version will be released early 2015 together with Plasma 5.2, although I’d like to roll a stable version first, so distributions can start adopting it.
