Tag Archives: sprint

Plasma Sprint 2023

BlaBlaSoftware

IT feels like a billion years before the last plasma sprint, which was in 2019 in Valencia, before the pandemic, but finally this year we are back on track, and was great to see again many old friends as well as seeing many new faces for which it was the first sprint.

We were gracefully hosted by Tuxedo Computers in Augsburgh, makers of very nice laptops that come with Linux and KDE Plasma, as well as being KDE patrons.

First of all, everybody got up to speed with a full git build of a Plasma 6 session, so that everybody could participate in development and discussions from the same level.

There were many discussions about Plasma 6, about what we want to do in Plasma and in Kirigami, how we want to change the look and defaults for the new major release. Most of the user-facing changes have been wonderfully described by Nate.

On my part, I worked on mainly 2 things, that were fairly not “glamorous” but quite important never the less (and mildly painful to do) : a refactor of the plasmoid loading code and splitting all the Svg themes code to a new framework with far less dependencies, ideally usable by any application.

Plasma API

I spent most of my hacking time at the sprint on a refactor of the plasmoid loading code, which won’t be really “seen” by the user, but will make the infrastructure much more robust and the API cleaner.

The person which must pay attention to it is the plasmoid author, which will need to adapt the plasmoid code in a few places.

Most notable is that, just like when you are writing a QML application you have to use the ApplicationWindow root QML Item, for a plasmoid you now have to use a PlasmoidItem root object, so something like

Item {
    Plasmoid.compactRepresentation: Label {text: Plasmoid.title}
    Plasmoid.fullRepresentation: Item {...}
}

becomes:

PlasmoidItem {
    compactRepresentation: Label {text: Plasmoid.title}
    fullRepresentation: Item {...}
}

A full porting guide is in progress.

KSvg

Using the Plasma Svg code to support stylesheet recoloring, on disk image cache to speed up loading, and the 9-patches FrameSvg is something the several applications would be interested to, and some actually are already doing, but since plasma-framework has a lot of dependencies, for some applications that is a blocker. All the svg code has now been broken out into a new framework called KSvg, which is still work in progress, but in the end will support all existing plasma themes with no change, and if an application wishes to use it, the svg sets will be loaded from the app own data folder (or anywhere else the application configures it to) instead of the share/plasma/desktoptheme folder, where plasmashell looks for them (so they can also use a complete different theme structure and don’t have to provide the same elements)

A week in Valencia

Software

From 19th to 25th of June, all the Plasma team gathered in Valencia, graciously hosted by the Slimbook people in their office. This was a special sprint, as it was co-located with the Usability sprint together with some VDG members. While some of the time each team was occupied in their own discussions, there were a big margin of overlap, allowing us to have a lot of discussions about the design and usability of our beloved Plasma desktop shell.

We now have plans in the coming months for several improvements across the board, including further improvements on the new shiny notification framework by Kai Uwe.

Also, we talked (and worked on) plans for further improving our Wayland support, including middle mouse button clipboard, and screen rotation for phone, tablets and 2 in 1 laptops).

On my end, a big part of this sprint was dedicated to an encompassing plan to refactor and redesign how desktop plasmoids work and are managed. I had there both UI discussions with the VDG and loong coding sessions on it.

The Desktop/FolderView containments use a big infrastructure written in Javascript which has some problems and isn’t touched much since a lot of time.

Some time ago I set myself the task of making the management of desktop plasmoids more touchscreen-friendly, so i started modifying that code, until.. I started to design a complete reimplementation written in C++ 🙂

This new implementation is much more robust, is faster and a bit leaner on the memory. Most important, is now a separate QML plugin, so is not anymore an implementation internal in the standard desktop, but if somebody wants to write his/her own containment for personalized plasma shells (for instance for a particular embedded device which is not a traditional desktop/laptop: we want plasma more and more usable as a set of construction blocks for the main UI of any kind of device).

In fact, it’s planned for Plasma Mobile to use the same layout manager component, to make the user experience “similar but different” and have less code duplication, while maintaining the UI very distinct between the two very different device types.

UI-wise in the desktop it doesn’t change much for now. the most notable difference is visible resize handles that make managing the layout and moving/resizing the plasmsoids much easier and more intuitive. Especially with touchscreen: now while manipulating plasmoids via touch, the resize handles become way bigger, and is possible to move and resize via a pinch gesture as well.

Lastly (for now!) the behavior during screen resolution switch improved a lot: if you connect a projector with a smaller resolution that relayouts your desktop, or play a fullscreen game at a tiny resolution, when the resolution is restored, everything gets back to normal, no more applets all over the place after changing resolution 😉

All of this should make it into Plasma 5.17.

A mobile Plasma Sprint

Software

I was last week in Berlin at the Plasma Mobile sprint, graciously hosted by Endocode, almost exactly 9 years after the first Plasma Mobile sprint in which we first started to explore Plasma and other software by KDE on mobile phones, which at the time were just starting to become powerful enough to run a full Linux stack (Hi N900!)

Now the project got a wide breath of fresh air: the thing that impressed me the most was how many new faces came at the sprint and are now part of the project.

Compared to 9 years ago, we have a way saner and more robust ecosystem to play on. Instead of a single (and quite underpowered) phone, which was the N900, now we can hack on a wide variety of phones, thanks to ARM being slightly less painful to work with compared to back then (even tough still a long way to go to be considered an open hackable system from nay point of view) Some devices are starting to get upstream mainline kernel support, and for those (unfortunately, most) who don’t there is the Halium project to the rescue, which provides an abstraction layer between the Android kernel and the “proper Linux” userland, making possible to use its graphjics drivers to drive a Wayland session, access audio and connectivity and so on.

We have a Neon version which supports a reference device (the old Nexus-5x) which can be easily adapted to other devices, and PostmarketOS, which is a distribution which supports many different phones and several user interfaces, Plasma Mobile being one of the official ones. At the sprint there were also some people from the PostmarketOS project: one of the things i love most of open source is when different projects collaborate so closely.

We had also some new toys to play with: people from Purism were also present, bringing development kits for their upcoming Librem5 phone, which will support mainline kernel and no need for closed Android drivers. Even tough a lot of work is stil lto do, Plasma Mobile already boots on the device.

Plasma Mobile running on a Librem 5 devkit.

As for Plasma Mobile software in itself, we did many bugfixes on the main shell/homescreen to have a better first impact, and a significant improvement came in KWin about high DPI scaling when running on an Halium system.

Also, many improvoements were done in the Kirigami framework, which is the main toolkit recommended to be used to build applications for Plasma Mobile: as developers of several applications that use Kirigami were present there, we could do very fast feedback and debug sessions.

KDE Plasma sprint

BlaBlaSoftware

Last week I went in Barcelona to the Plasma sprint with a bunch of old friends.
As usual it was a great experience, but let’s talk about results 🙂
The framework architecture is being finalized, compared to Plasma1 it will be way simpler. the Plasma framework will be a nice lean library (an order of magnitude smaller than Plasma1) accompained by a runtime component: a series of plugins provided as QML2 imports and the runtime environment, the Plasma shell, that will run Plasma Desktop, Plasma Active and Plasma Netbook (and any other you can imagine and write 😉 and even switch the shell at runtime. This is possible because the shell binary is pure logic, it doesn’t have any UI whatsoever.
The coding I did during the sprint was mostly on this area, especially a refactoring on how QML plasmoid are loaded by the shell and written, that should lead to faster startup and cleaner code.. but since is all stuff under the hood, no fancy screenshot tis time, sorry :p

The default Desktop experiece will be at first not too dissimilar to the one of Plasma1, a big focus will be on redesigning the singular components around simplicity and elegance (see here) rather than big changes in functionality altogether.
A set of visual guidelines is being developed, that will help any developer to make their plasmoid elegant and well integrated.
Changes can always come a bit at a time once the new technology is well road tested.

The Randa platform meeting

BlaBla

Last year, a bunch of KDE hackers gathered together in the little lovely swiss village of Randa in a meeting that was called Platform 11 (actually the third KDE meeting held in Randa).

That quite large meeting turned out to have been one of the most productive ever. Developers from all areas of KDE, from libraries and platforms targeted to other developers to applications (built with those libraries) targeted to end users.

A lot of design and development work happened on the KDE Frameworks 5 happened. This is crucial for the future of the KDE applications and workspaces, because besides porting to the soon to be released Qt5, it will make the KDE libraries much more modular, making easier for any application developer to just cherry pick between the features offered by the the KDE frameworks and use them on any platform without significant dependencies, being Linux, Windows, Mac, Android…

You can help this meeting to happen, as usual the development is done by volunteers, but there are some fixed expenses, like food and travel. There is a fundraising campaign for this on Pledgie, of which we are already at a good point, so yeas, you can make the diffeernce 🙂

Click here to lend your support to: KDE Randa Meetings and make a donation at www.pledgie.com !