Tag Archives: akademy

Akademy 2021

It’s the second day of Akademy (for the second year, in an online form, for obvious reasons) and still a full week of goodness to come with a lot of interesting bofs and social events.

I gave a talk about the future of Plasma and what to expect from Plasma 6 as an architectural standpoint. How we can make things simpler, faster, more stable and more intuitive to develp against. (Sorry, no pretty pictures here ðŸĪŠ)

Here is a synopsis of my talk (slides here), I hope it’s clear enough to the occasional reader:

The topic of this talk will be unfortunately very far removed from pretty pictures, I’m going to talk about the non visible aspects of Plasma: The structure of Plasma Framework, how the desktop is loaded, what basic api a developer can use to write a plasmoid.
For those who attended yersterday training by Kevin, the first part will have some repetitions, but let’s refresh it a moment, then i will talk about some deas on how to streamline it and what changes we would like to have for KF6/Plasma6

First of all, a bit of history: Plasma was introduced with KDE 4.0, in those “interesting” times 🙂

Back then, the structure was as follows:
It was based on a Qt technology called QGraphicsView, which nowdays is kinda deprecated. Plasma doesn’t use it anymore, some apps still do, like the Dolphin icon view, still used a lot in Gwenview, and something will need to be done about it.

The center was a QGraphicsScene, called the Corona, which seems incredible nowdays but it was a complete innocent name back then! (referring to the Sun Corona, where the Plasma lives)

The Corona loads inside its scene QGraphicsWidgets objects called Containments, and manages views for each containment: every containment that is associanted to a phisical screen, will have a correspondece 1:1 with a view and views can be eother of Desktop type or Panel type

Each Containment can contain many Applets, which will be either desktop widgets or panel components like the start menu, task manager and so on, and containment itself is a particular type of Applet, so it’s a subclass of it.

Applets own a Package of files, together they form a Plasmoid. Plasma::Package was then splitted out of Plasma-framework and became the KPackage framework

In this way is possible for the user to build its own perfect desktop ui out of a vast choice of pieces.

In KDE4 times, Plasma supported a wide variety of bindigs, even if most of the applets were implemented in C++
We had pure javascript (before QML wasa thing), Python, Ruby and later we added QML support.

In Plasma5 things changed quite a lot, as it was obvious that QML was going to be the future, and qgraphicsview was having huge performance problems (when resizing large applets it could go down even to 4-5 fps)

So we went all with the QML scenegraph, having much faster and hardware accelerated things in the process.
Corona, Containment and Applet are no more graphical objects but judt QObjects that manage only logic, not the visualization having a better separation
On the downside that meant that the qml binding became the only way to write plasmoids, losing the possibility for using Python and Ruby, but all the binding infrastructure remained there, which became a significant overhead without a real reason.

So now with KF6 coming: What parts of the Plasma architecture are still needed and mostly ok? what are kinda redundant and not necessary anymore? should we split something? how we can improve things in general?

A thing we should split is the Plasma Svg support, just like KPackage can be really useful elsewhere for apps as well. Even if is just for basic svgs, due to QtSvg it’s based on, It adds some nice features on top: caching of the rendered images which helps a lot with load times, it can optionally color svgs with stylesheets and offers support for those nine patch rounded rectanles rendering with sone support for hardwaare acceleration when used on QtQuick. IT has both QtQuick and classic QPainter based API

One that should probably instead be dropped are Dataengines: they were designed with the limited JavaScript api in mind and had quite a hefty goal: to give a common async job based api to access all kind of information, even remotely, to stream informations also on widgets of another computer (KDE4 had thins kinda working)
However in the end the implementations ended up being not so good with pretty ugly code.
With QML it became way easier to just bind QObjects with properties, signals and slots for the logic instead.
They can go in a Plasma5Support porting aid in Workspace

The parts that loads the layout from disk to a Loading the layout from disk to a qobject representation are pretty good right now, and save for some API fixes it can be very similar in Plasma6 as well.
The layout is saved in the appletsrc file, which at startup is read by the Corona and reads the first level of the config file, which represents the containments, that will be instantiated from the plugins.
Corona will check what containments are assigned to a screen which is connected, and those will get a QQuickView, both panels and desktops.
At this point containments will load all the applets in them and instantiate also the corresponding QML and use their oown internal logic to layout the applets, as linear layouts in panels, flee floating in desktops.

Another important part are shell packages
They were born in Plasma Active to do a mobile optimized shell, then the shell of Plasma Active basically became the Plasma5 unified shell for every device and the shell packages are here too, to allow some personalization to adapt the shell to a different kind of device, ad desktops, phones, mediacenters and so on have different ui requirements
In Plasma6 i would like them to be a bit more powerful.

ScriptEngines are a way to wrap the Api of Applet Containment and so on, in a more “limited” way, so that the kde4 times javascript bindings could use them without being “dangerous” Unfortunately those are still used in the QML plasmoids nowdays, but the whole infrastructure should be removed. I would still like some way to bring back Python in plasmoids, but with a different mechanism compared to old scriptengines

I made a prototype as a Plasma-framework fork in my personal area on invent: https://invent.kde.org/mart/Plasma-framework is still not completely functional, but i do have a very simpleshell loading a qml containment and a plasmoid inside it which removes all of the AppletScript intermediary, and the “plasmoid” object is directly the Applet* instance, not a wrapper anymore.

The first phase of loading works in the same way, corona reads appletsrc, instantiates the Containments and in turn the containments instantiate the Applets.
The shell creates the actualwindows, a view for each containment which is associated to a screen, the view when gets assigned to a containment ensures the QML ui for the containment is loaded.
The QML part of the containment, when it gets a new Applet*, it creates an object of type AppletContainer which will take care of making sure that the qml part of the applet is loaded, and this will go in whatever layout manager the Containment implements.

The QML part of an Applet is as is now, shipped in a KPackage.
Now, the root element instead of being an arbitrary item, is forces to be a particular one: AppletRepresentation (error if that’s not the case) its api is purely providing components property for the compact and full representation.

This is a very basic example:

import QtQuick 2.15 //3
     import QtQuick.Layouts 1.0
     import org.kde.plasma.core 6.0 as PlasmaCore
     import org.kde.kirigami 2.15 as Kirigami
     18 – 25 June 2021
     PlasmaCore.AppletRepresentation { // This non graphical element is the mandatory root, won't load with a different one
         // As is today, 99% on the times shouldn't need a compactrepresentation
         compactRepresentation: Kirigami.Icon { // Hopefully this can replace PlasmaCore.IconItem
             source: "start-here"
             TapHandler {
                 onTapped: PlasmaCore.Plasmoid.expanded = !PlasmaCore.Plasmoid.expanded
             }
         }
         fullRepresentation: Item {
             Layout.minimumWidth: Kirigami.Units.gridUnit * 10 //plasmacore units should be migrated to Kirigami
             Layout.minimumHeight: Kirigami.Units.gridUnit * 22
             Text {
                 text: PlasmaCore.Plasmoid.title // all accesses to PlasmaCore.Plasmoid are pointers to the same Applet* instance
             }
         }
     }

Most on the times, compactRepresentation is not needed, the default shell-provided icon will be used but can be overridden if needed (or explicitly be set to null if we want applets to not be collapsible, like the task manager)

The shell packages may become more powerful if we instead of providing root items for the views, which are desktops, panels and config dialogs, they can provide the view window themselves, so that those views can be custom provided plugins as well, perhaps also useful for very custom panel containments, like Latte Dock, to be able to be loaded in the same Plasmashell process.

Akademy 2018

BlaBlaSoftware

The time for Akademy came this year as well, this year it was in the gorgeous Vienna, Austria.
This year marks my 10th Akademy in a row, starting from my first one in Belgium in 2008.
Talks have been awesome as usual, but what’s always awesome for me year by year is all the face to face conversation with so much diverse and smart people in out awesome KDE community.

Kirigami

For me the highlight was the BOF session on Kirigami, in which some nice plans, together the VDG are starting to form.
Kirigami in a QML based UI framework at the core of some KDE applications, which will become more and more central as more and more QML based applications are made.
So far is still a relatively unknown gem in the KE software and frameworks offering, however as technologically is starting to mature, we’ll start to advertise it more and simplify onboarding.
A big part of that will be about web presence and documentation:

  • A nice media-heavy introductory website which will showcase the features it can offer to your app, together expanded sections of the central Kirigami UX patterns in the new Human Interface Guidelines website.
  • Improving the API documentation
  • The Kirigami channel on Telegram will need IRC and Matrix bridges
  • A series of tutorials how to get started developing applications using the Kirigami toolkit
  • Repurpose the example “Kirigami Gallery” application: It will become a showcase of components and UI patterns the developer is recommended to use: each gallery page will also have documentation text together links to the corresponding HIG page and to the gallery page sourcecode itself, to be used as a source of inpiration and best practiches to be used while developing your application

Kirigami Gallery on the Cards pattern, mobile version

Kirigami Gallery on the Cards pattern, desktop version

If you think you can help on this web presence effort, you are welcome to join 🙂

Plasma

On the Plasma side, many plans of improvement have been discussed and are on their ways, such as better support for touch-based convertible laptops, a completely rewritten and overhauled notification system, and improved Virtual Desktops/Activities infrastructure and UI, on Wayland too.
But, more on all of this in the future 🙂

Vienna

Vienna is a really charming and beautiful city, I would totally recommend going there at least once.


It’s home not only to great musician in the past:

Mozart


But also to Important scientists that contributed so much to the knowledge of humanity and.. contributed a littel bit making possible all the technology we know and love 🙂

Meow!

Plasma Workspace: present and future

We saw last week the release of the first beta of KDE Plasma Workspace and applications 4.11

From my side, that’s a very important milestone, because it’s pretty much the coronation of what we intended the 4.x series of the workspace to be. It was a long ride, but I think this future release will be pretty stable and “defined” in its own identity.

The 4.11 release of the Workspace will be supported for years to come, marking in fact the last big feature release of the 4.x series.

This sounds pretty scary, but it indicates a lot of maturity, 4.11 will be a release you can count on being maintained abd bugs fixed for a long time. Nice for home users, utterly awesome for bigger deployments.

Just to clarify: this regards only Plasma Workspace so far. Applications will continue feature releases as usual, after all KDE is not a software, is a community that releases a lot of eterogeneous pieces of software.

So, were are now?

  • The desktop shell is useful by default. A default setup has all the typical functionality that a typical desktop usage needs, but.. one size does not fit all.
  • The desktop shell is very flexible, trying to not force a paradigm on you, assemmble it at your liking.
  • We have at least 5 different shells: Desktop, Netbook, Plamsa Active, Media center, part for application dashboards. Because one size does not fit all, on different devices we try to give you the best experience given the particular device.
  • QML: It’s very easy to write new components for your desktop/tablet/mediacenter/whatever with an easy scripting language.

But of course we never are happy: we want to do new things and have new features in the future..

  • We are porting to Qt5 and QML2
  • The whole workspace will be rendered by the GPU: faster and will be possible to have beautiful effects.
  • We will have one shell to rule them all: the actual Plasma Shell becomes just a generic “viewer” with no UI whatsoever by itself. Since all the UI elements will be done by QML, they can be loaded and unloaded, so a different device experience can be dynamically loaded when for instance you plug your tablet to a docking station, the full Desktop shell starts.
  • Even tough it will mean a quite big technology change, since we are quite happy with the overall direction of each one of our shells, there won’t be radical UI changes, except of course the usual incremental upgrades and refinements.

I’ll do a talk about Plasma2 at Akademy, going a bit more in deep about the technology, the big picture concept and how to get involved in, so see you there 🙂

I'm going to Akademy

minor but nice details

BlaBla

These days at akademy i really couldn’t do that much in the code perhaps i’m lazy and i left the laptop turned off (and the brain too:) from quite some days.

By the way so far it’s really fantastic and insanely tiring, yaaawn (i don’t ride the bike THAT much usually) 🙂

this photo

A little thing i managed to get done it’s a graphics change in plasma widgets and applets that have a scrollbar in it.

The Oxygen scrollbar was not really suited in plasma applets, both for its style and its colors, arrow button black on black with a flashing blue handle wasn’t really it in the plasma style… so now it’s svg themed too as other widgets.

it’s not really pretty as code but was really the least worst way, it uses a qstyle that must be explicitly set for each scrollbar, but it’s totally hidden from the api, since only widgets in kdelibs uses this thing, so just use widgets/
ScrollBar or TextView and all is done (hmm, i suppose i’ll have to provide also a set of treeview/listview and stuff so…).

Plasma everywherer than qt

BlaBla

First post at akademy i can only say this thing is amazing at the moment non on my laptop and the ethilic grade is uhm nice…. probably i will write a more “meaningful entry” waaay later…

Actually at the moment our Plasma on mobile devices GSOC god is very busy porting Plasma to these particular soda bottles. After hours of hard labour Martijn already got a initial version running – using the nice curly backround (which blends in perfectly!!).