I didn’t work much on KDE for the first half of March, but still managed to squeeze out some good features and bugfixes. I’m also starting on the Wayland grant work I teased soon, so look forward to news on that next month.
[Feature]
Allow popping out the status composer on desktop. This allows you to compose toots while doing something else in the application, like browsing or searching for the correct hashtag.
[24.05]
[Bugfix]
I implemented more key navigation fixes. This set of fixes are centered around interacting with media attachments. There’s still a long way to go before you can use Tokodon from a keyboard alone, but it’s getting there.
[24.05]
[Bugfix]
Now lonely question marks are excluded from links as they should be. Websites that don’t handle this will throw up an error instead, so this eliminates lots of user error.
[24.02]
Lots of small UX changes this month. Including moving more actions to the header, reducing video title duplication and more. I can’t make a good screenshot right now because Invidious is currently broken due to Google’s changes.
[24.05]
I'm bit late to the train of Plasma 6 related posts... But anyway.
I will go through some things I did.
For me working on Plasma 6 was pretty fun, I learned a lot of new things and
fixed bunch of bugs and crashes.
The most resourceful ones can find my merge requests, but I am too lazy to link
them all.
Things I did
Most of the things I did were a lot more in the background. I hunted down a lot of bugs and crashes,
and tried to fix them myself or helped others fix them, in various projects, such as:
Dolphin
Plasmashell
Kwin
KNS
And probably a lot of more I have already forgot... :D
But there was A LOT stuff: Around 100 merge requests in total!
Pretty much all of them got in, thanks to all the reviews and education other KDE developers provided to me! :)
Again, thanks to everyone who has helped me to work on KDE projects!
Thanks for your patience with me and all the knowledge you have parted to me. ❤️
I'll keep doing my best helping KDE projects, be it bug hunting or feature creation.
I have to say my software testing background has been very useful when it comes down
to hunting down bugs, and I've learned a lot of things about Qt, C++ and QML. Still got much
more to learn though, but that's what makes me so excited about programming!
I think one of the most useful things I've learned is how to use GDB. I can't provide
anyone a crash course (at least in this blog post) but it is essential when hunting down
weird bugs in plasmashell for example. I love debuggers integrated to editors like using LLDB-DAP in Kate,
but sometimes GDB in terminal is all you can use, so it's good idea to learn to use it!
One big thing I worked on with others was fractional scaling related stuff: I didn't do any of the Kwin stuff around it,
but I hunted down some weird bugs with window decorations having some weird gaps in them when windows are specific size.
Hunting down all these bugs and weirdness took long time, and we're still looking into it, since it seems to be different in every system..
Floating point numbers and computers are very weird combo.
Another more visible thing I did was unifying separator colors and other items, you can find an issue about it here: Frame and outline color consistency and high-contrast setting changes.
I have been bothered by the random differences between some elements, which can be especially noticeable in darker colorschemes,
so I finally sat down and combed through related codebases. There's likely more to fix though, but there is now easy way for us to add
high-contrast support for outlining elements! It just needs doing, and I haven't had the time.. Yet. :)
Things I learned
GDB is a life saver
Write down notes. All the time.
Journaling is a good idea!
Working in open source is a lot about the social aspects!
Be nice to people! Duh!
But also don't let people walk over you!
Listen to others, and don't be afraid to share your opinion.
Ask many questions and write down the answers.
Be patient
Bug triaging is tough, but very important!
Remember to rest (I'm bad at this)
Things I will do in future
I will continue hunting down various bugs and crashes and fixing them whenever I spot some, or
something is raised to me as "hey this looks like something you could do."
I have also started working on couple things related to remote desktop:
Last but not least, I have looked into facelifting our dear Breeze theme, just a lil bit. Nothing drastic,
some tell me they don't see any change and some do. But hopefully it would make Breeze look
just a lil bit "softer" and "friendlier." :) You can see them here: Slightly rounder elements, slightly lighter outlines
All in all I am very happy with my current job working on KDE projects, fixing bugs and creating new cool things.
I also kind of enjoy being a jack-of-all-trades (master of none),
since I get to do a lot of different kinds of stuff, from something more "background"
like KWin and plasmashell to something more visible like Breeze and Dolphin.
Maybe eventually I will specialize around something, but for now I am bit all over the place which is fine by me lol.
I hope that some of my work has helped you as well. :)
I'll keep doing my best and learning more. (And hopefully write more blogposts.. lol.)
A global theme on the kde third party store had an issue where it executed a script that removed user's data. It wasn't intended as malicious, but a mistake in some shell parsing. It was promptly identified and removed, but not before doing some damage to that user.
This has started a lot of discourse around the concept of the store, secuirty and upstream KDE. With the main question how can a theme have access to do this?
To developers it's not a surprise that third party plugins can do this sort of thing. It's as intended. A global theme can ship custom lockscreens, custom applets, custom settings and all of these can run arbitrary bundled code. You can't constrain this without limiting functionality.
To that end there's an explicit warning when downloading plugins.
Expectations
Our primary issue boils down to expectation management and communication.
There are plenty of other ways where users can download and run any other unfettered code from the internet; the Arch user repository (AUR), adding ubuntu PPAs and alike. This isn't a bad thing - it's useful and people do amazing things with this to benefit users.
Nothing on the KDE store happens without explicit user interaction either.
A problem is there's an expectation that because it's programs that it's inherently unsafe and a user needs to trust the source. Our issue is phrases like "global themes" or "Plasma applets" don't always carry this message.
The tech world has changed a lot over the past decade and whilst our code hasn't changed, users expectations have. More and more places provide well kept walled gardens where most actions accessible via the UI are safe-by-default - or at least claim to be!
I've also seen confusion that because a lot of our UI is written in a higher-level language (QML) that's enriched with javascript all browser sandboxing automatically applies. Even though that's not what we claim.
But ultimately if there is a gap in expectations, that's on us to fix.
What can we do better?
In the short term we need to communicate clearly what security expectations Plasma users should have for extensions they download into their desktops. Applets, scripts and services, being programs, are easily recognised as potential risks. It's harder to recognise that Plasma themes, wallpaper plugins and kwin scripts are not just passive artwork and data, but may potentially also include scripts that can have unintended or malicious consequences.
We need to improve the balance of accessing third party content that allows creators to share and have users to get this content easily, with enough speed-bumps and checks that everyone knows what risks are involved.
(UI from Flathub for potentially unsafe content)
Longer term we need to progress on two avenues. We need to make sure we separate the "safe" content, where it is just metadata and content, from the "unsafe" content with scriptable content.
Then we can look at providing curation and auditing as part of the store process in combination with slowly improving sandbox support.
Do I need to do anything as a user?
If you install content from the store, I would advise checking it locally or looking for reviews from trusted sources.
If you're a sys-admin you might want to consider adding the following to block users installing addons with the following kiosk snippet.
For the next digiKam releases, the digiKam team needs photographs for digiKam and Showfoto splash-screens.
Proposing photo samples as splash-screens is a simple way for users to contribute to digiKam project. The pictures must be correctly exposed/composed, and the subject must be chosen from a real photographer’s inspiration. Note that we will add a horizontal frame to the bottom of the image as in the current splashes.
Since the dawn of the times, the only way to implement any effect that has fancy user interface used to be in C++. It would be rather an understatement to say that the C++ API is difficult to use or get it right so there are no glitches. On the other hand, it would be really nice to be able to implement dashboard-like effects while not compromise on code simplicity and maintainability, especially given the rise of popularity of overview effects a few years ago, which indicated that there is demand for such effects.
In order solve that problem, we started looking for some options and the most obvious one was QtQuick. It’s a quite powerful framework and it’s already used extensively in Plasma. So, in Plasma 5.24, we introduced basic support for implementing kwin effects written in QML and even added a new overview effect. Unfortunately, if you wanted to implement a QtQuick-based effect yourself, you would still have to write a bit of C++ glue yourself. This is not great because effects that use C++ are a distribution nightmare. They can’t be just uploaded to the KDE Store and then installed by clicking “Get New Effects…”. Furthermore, libkwin is a fast moving target with lots of ABI and API incompatible changes in every release. That’s not good if you’re an effect developer because it means you will need to invest a bit of time after every plasma release to port the effects to the new APIs or at least rebuild the effects to resolve ABI incompatibilities.
This has been changed in Plasma 6.0.
In Plasma 6, we’ve had the opportunity to address that pesky problem of requiring some C++ code and also improve the declarative effect API after learning some lessons while working on the overview and other effects. So, enough of history and let’s jump to the good stuff, shall we?
Project Structure
Declarative effects require some particular project structure that we need to learn first before writing any code
The package directory is a toplevel directory, it should contain two things: a metadata.json file and a contents directory. The metadata.json file contains information about the name of the effect, what API it uses, the author, etc.
The contents directory contains the rest of QML code, config files, assets, etc. Keep in mind that ui/main.qml is a “magical” file, it acts as an entry point, every effect must have it.
In order to install the effect and make it visible in Desktop Effects settings, you will need to run the following command
This is quite a lot to memorize. That’s why kwin provides an example qtquick effect that you can grab, tweak some metadata and you’re good to go. You can find the example project at https://invent.kde.org/plasma/kwin/-/tree/master/examples/quick-effect?ref_type=heads. Note that the example project also contains a CMakeLists.txt file, which provides an alternative way to install the effect by the means of cmake, i.e. make install or cmake --install builddir.
Hello World
Let’s start with an effect that simply shows a hello world message on the screen:
import QtQuick is needed to use basic QtQuick components such as Rectangle. import org.kde.kwin imports kwin specific components.
The SceneEffect is a special type that every declarative effect must use. Its delegate property specifies the content for every screen. In this case, it’s a blue rectangle with a “Hello World!” label in the center.
The ShortcutHandler is a helper that’s used to register global shortcuts. ShortcutHandler.name is the key of the global shortcut, it’s going to be used to store the shortcut in the config and other similar purposes. ShortcutHandler.text is a human readable description of the global shortcut, it’s going to be visible in the Shortcuts settings.
The ScreenEdgeHandler allows to reserve a screen edge. When the pointer hits that screen edge, some code can be executed by listening to the activated signal.
The PinchGestureHandler and SwipeGestureHandler allow to execute some code when the user makes a pinch or a swipe gesture, respectively.
effect.visible = !effect.visible toggles the visibility of the effect. When effect.visible is true, the effect is active and visible on the screen; otherwise it’s hidden. You need to set effect.visible to true in order to show the effect.
If you press Meta+H or make a pinch gesture or move the pointer to the top screen edge, you’re going to see something like this
Note that there are no windows visible anymore, it is the responsibility of the effect to decide what should be displayed on the screen now.
Displaying Windows
Being able to display text is great, but it’s not useful. Usually, effects need to display some windows, so let’s display the active window
The change is quite simple. Instead of displaying a Text component, there’s a WindowThumbnail component now. The WindowThumbnail type is provided by the org.kde.kwin module. WindowThumbnail.client indicates what window the thumbnail item should display.
Input
Input processing contains no kwin specific APIs. TapHandler, MouseArea, Keys and other stuff available in QtQuick should just work. For example, let’s implement an effect that arranges windows in a grid and if somebody middle clicks a window, it will be closed
The code looks pretty straightforward except maybe the model of the GridView. WindowModel is a helper provided by org.kde.kwin module that lists all the windows. It can be passed to various views, Repeater, and so on.
The result can be seen here
Delegates are Per Screen
One thing to keep in mind is that the delegates are instantiated per screen. For example,
delegate: Rectangle { color: "yellow"
Text { anchors.centerIn: parent color: "black" text: SceneView.screen.name } }
When you activate the effect on a setup with several outputs, each output will be filled with yellow color and the output name in the center
Usually, the output is irrelevant, but if you need to know what output particular delegate is displayed on, you could use the SceneView.screen attached property.
Configuration
As your effect grows, you will probably face the need to provide an option or two. Let’s say that we want the background color in our hello world effect to be configurable. How do we achieve that? The first step, is to add a main.xml file in package/contents/config directory, i.e.
In our case, only one option is needed: BackgroundColor, which has Color type and #ff00ff default value. You can refer to the KConfigXT documentation to learn more what other entry types are supported.
The next step is to actually use the BackgroundColor option
effect.configuration is a map object that contains all the options listed in the main.xml.
Now, if you toggle the hello world effect, you’re going to see
There are a few more thing left to do though. If you navigate to Desktop Effects settings, you’re not going a configure button next to the hello world effect
Besides providing a main.xml file, the effect also needs to provide a config.ui file containing a configuration ui
The config.ui file is a regular Qt Designer UI file. The only special thing about it is that the controls that represent options should have special name format: kcfg_ + OptionName. For example, kcfg_BackgroundColor
The last final piece in order to expose the configuration ui is to add the following line in the metadata.json file
"X-KDE-ConfigModule": "kcm_kwin4_genericscripted"
With all of that, the effect is finally displayed as configurable in the system settings and the background color can be changed
Sharing Your Effect With Other People
The preferred method to distribute third party extensions is via the KDE Store. Both JS and QML effects can be uploaded to the same “KWin Effects” category.
Documentation and Other Useful Resources
Documentation is still something that needs a lot of work (and writing it is no fun ). KWin scripting API documentation can be found here https://develop.kde.org/docs/plasma/kwin/api/.
If you need to pack or arrange windows like how the overview effect does, you could use the WindowHeap component from org.kde.kwin.private.effects module. BUT you need to keep in mind that that helper is private and has no stable API yet, so use it on your own risk (or copy paste the relevant code in kwin). Eventually, the WindowHeap will be stabilized once we are confident about its API.
I hope that some people find this quick introduction to QML-based effects in KWin useful. Despite being a couple years old, declarative effects can be still considered being in the infancy stage and there’s a lot of untapped potential in them yet. The QML effect API is not perfect, and that’s why we are interested in feedback from third party extension developers. If you have some questions or feedback, feel free to reach out us at https://webchat.kde.org/#/room/#kwin:kde.org. Happy hacking!
Since a brief tryst with Ubuntu Budgie Edition, I’ve dearly missed its Raven side-panel, a special panel on the side of the screen that can be opened and closed with a click. As someone who needs a clean, minimal desktop, the workflow is just too perfect — when you have two or three widgets that you use frequently, but not frequently enough that they warrant permanent homes on a main panel, just stuff them into a disappearing side-panel that can be called with a quick key-combination or by clicking on an icon; It’s a great way to keep things out of the way, but within reach, without having a permanently cluttered system tray that you might want to keep clear for things like email notifications.
My side panel, and the widget that launches it.
There are some drawbacks; this workflow isn’t well supported on KDE Plasma, so it’s a bit of a faff to set up, and only a few widgets will display nicely on a wide side-panel. For instance, it would be a dream to have the KDE weather widget automatically take advantage of the horizontal space and display the information that would usually be in its dropdown, but what you get instead is a giant icon, for now at least. I use my side-panel for my clipboard history and the media player widget, both of which play nicely with a side-panel. Another niggle I have with it is that, as far as I know, there’s no way to disable activation of the panel when your mouse pointer makes contact with the screen edge. This is a mild to moderate inconvenience when you’re working with applications that have toolbars on the sides of the window, like design applications often do.
For me, personally, the drawbacks aren’t so severe as to put me off of the workflow.
First, you’ll need to create a panel. To do this, right click on an empty section of your desktop, and select “Add Panel > Empty Panel.” When the panel appears, right click it and select “Enter Edit Mode.” Set up your panel however you like, but you will need to set “Visibility” to “Auto Hide” and may want to give it a width of at least 400px or so.
Now, if you wanted to show and hide your panel with a keyboard shortcut, you can set up a focus shortcut in the panel settings window and stop here. If, like me, you want to toggle your panel by clicking on an icon somewhere, we’re going to have to use a wee script, but don’t worry, it’s not as hard as it sounds and I’ll take you through it step by step.
Before we can put our script together, we’re going to need to know what the ID of our panel is. Open up KRunner with Alt+F2 or Alt+Space and run plasma-interactiveconsole. This will launch KDE’s Desktop Shell Scripting Console. In the console, type print(panelIds); and click “Execute.” Assuming you entered that in correctly, what you should see now in the output console beneath the text editor is a series of numbers — the ID numbers of our panels. Keep a note of these numbers.
Look at those IDs.
Clear the text editor and enter the following:
let panel =panelById(401);
panel.hiding ==="autohide"? panel.hiding ="windowsgobelow": panel.hiding ="autohide";
This will check if our panel is set to auto-hide; if it is, the script will set the panel to “windows go below” mode, otherwise it will set the panel to auto-hide.
Now to make use of those panel ID numbers. Which number corresponds to your new side-panel? While I can’t be sure, chances are it’s the last number on the list as we’ve just made the new panel a moment ago. So in the script above, where I have entered 401, enter the last number in your ID list and click “Execute.” At this point, if the ID number is correct, your panel should appear; click “Execute” once more to hide it.
Alright, we’ve got our script ready, so we just need one more thing in place: a button or icon that we can click on to show and hide the panel. Fortunately, we can use a widget called “Scriptinator” to provide just this. Right click on an empty area of your desktop or a panel, click “Add Widgets,” and “Get New Widgets.”
Let’s get that widget.
From here, find and install Scriptinator. Once installed, simply drag it where you’d like it to live, either on your desktop, or on a panel. Once you’ve done that, right click on the widget and choose “Configure Scriptinator.” Here, enter the path of the icon you’d like to use in “Custom icon full path;” I used /usr/share/icons/breeze-dark/actions/22/sidebar-expand-right-symbolic.svg. In “OnClick Script,” enter the following:
If you’ve done everything correctly, you should see your side-panel appear when you click the widget and disappear when you click a second time. You may need to restart to see your icon applied to the widget; if you don’t want to wait, you can drop the file path into “OnClick icon full path” in your Scriptinator configuration.
We have a release of Kile 2.9.95, also known as 3.0 beta 4! Earlier today, Michel Ludwig tagged the current Git master. This is the first beta release since October 2019. Beside the port to KDE Frameworks 6 and Qt 6, it provides a couple of new features and bug fixes.
New features
Port to KDE Frameworks 6 & Qt 6 (Port by Carl Schwan)
Enable high-dpi support
Provide option to hide menu bar (Patch by Daniel Fichtner, #372295)
Configurable global default setting for the LivePreview engines (Patch by Florian Zumkeller-Quast, #450332)
Remove offline copy of "LaTeX2e: An unofficial reference manual", use online version instead (Patch by myself, Christoph Grüninger, Issue #7)
Fixed bugs
Kile crashes on selecting "Browse" or "Zoom" for document preview (Patch by Carl Schwan, #465547, #476207, #467435, #452618, #429452)
Kile crashes when generating new document (Patch by Carl Schwan, #436837)
Ensure \end{env} is inserted in the right place even when the user uses tabs for indentation (Patch by Kishore Gopalakrishnan, #322654)
Avoid saving console commands in bash history (Patch by Alessio Bonfiglio, #391537, #453935)
redstrate
@redstrate:pyra.sh
GSoC
). KWin scripting API documentation can be found here 
