Tellico 3.5.4 is available, with a few fixes.
For a while Qt has been offering qmlls, a Language Server Protocol implementation for QML. This allows popular text editors like Kate (and some lesser known ones like Visual Studio Code) to work with QML code without having to write dedicated support for it.
Naturally many people are eager to use it to hack on KDE code. When trying to do that you probably have encountered some frustration with things not working as expected. So what’s going on there, and how can we make it work?
First and foremost one must mention that qmlls is still under heavy development. There’s a number of things missing that you’d expect from a fully featured LSP implementation. If you encounter something that looks like it should work but doesn’t, don’t hesitate to file a bugreport.
So how does one use qmlls? In Kate it should be activated out-of-the-box when opening a QML file. If that doesn’t work you might need to tweak the LSP-Client settings. For other editor please consult their documentation on how to enable LSP support.
One problem you are likely to encounter when using qmlls on KDE code is that it fails to find KDE-provided QML modules like Kirigami. This happens when the modules are installed into e.g. ~/kde/usr, which isn’t searched by Qt. One way to get around this is to build and install your own Qt into ~/kde/usr too, since that way the modules will be installed into the same prefix as Qt and Qt will find them. While building your own Qt is a worthwile thing to do in general it’s not a very satisfying solution. I hope we can find a better solution for this soon. See here for a related bugreport.
If your installation is set up in a way that qmlls can find the KDE-provided modules you might still encounter it warning on unknown modules or types. In order for qmlls to show information for a module the module needs a qmltypes file. These files provide machine-readable information about the types that the module exposes. The easiest way to make these available is porting the module to ecm_add_qml_module and declarative type registration. This was done for many KDE modules already, but there’s still a number of them missing. Help on that is very welcome! Something that isn’t obvious is that in order for the tooling to work correctly module dependencies need to be marked explicity via the DEPENDENCIES parameter in ecm_add_qml_module.
If all the modules and types are found correctly you will still encounter some warnings, but most of these should correspond to actual issues and non-optimal practices like using unqualified property lookups and context properties. qmlls is a great tool to guide you towards resolving those and thus modernizing and optimizing the code. There are however some classes of warnings for which we don’t have proper solutions yet:
nicofeekcm context property, which is opaque to the tools. A different approach is needed.Despite the current limitations qmlls is already a very useful tool for working on QML code, assuming the project is set up properly.
Happy QML hacking!
If you are reading this from the future there’s an update available.
Let’s go for my web review for the week 2024-12.
Tags: tech, gdpr, law, surveillance
It’s not the regulation which brings the banners, it’s the companies insisting on tracking us.
https://www.amazingcto.com/cookie-banners-are-not-needed/
Tags: tech, security
This is bad. Unlocking many doors is just a couple of taps a way if you’re already a guest.
https://www.wired.com/story/saflok-hotel-lock-unsaflok-hack-technique/
Tags: tech, apple, vr
Very thorough analysis of the Vision Pro value proposition. It shows quite well where it shines and where it should be improved.
https://hugo.blog/2024/03/11/vision-pro/
Tags: tech, gpt, copilot, economics
The price hike on the generative AI services will happen sooner or later. That much is clear.
https://www.theregister.com/2023/10/11/github_ai_copilot_microsoft/
Tags: tech, programming, ai, machine-learning, gpt, copilot
Definitely this. It might ultimately impact the abstraction levels accessible to us for coding… but the skills will still be needed. Natural language is too ambiguous for the task.
https://muratbuffalo.blogspot.com/2024/03/the-demise-of-coding-is-greatly.html?m=1
Tags: tech, c++, complexity
When guidelines contradict each other. You need a proper way to communicate where a piece of code stands.
https://arne-mertz.de/2024/03/core-guidelines-are-not-rules/
Tags: tech, python, performance
As usual measure and don’t just assume when you want to optimize something. This is an interesting case in Python using Numba.
https://pythonspeed.com/articles/slow-numba/
Tags: tech, web, frontend, performance
Indeed this. It’s not only about payload size, it’s also about CPU consumption. Our profession is still assuming too much that users will get faster CPU on a regular basis.
https://danluu.com/slow-device/
Tags: tech, mobile, obsolescence
Interesting paper showing the main reasons why people ultimately change their phones. I find interesting that the opacity of storage management on mobile devices is such a factor.
https://hal.science/hal-04097867
Tags: tech, tests, tdd, quality
Indeed, don’t mindlessly add tests. I find interesting that the doubts raised in this piece are once again concluded using an old quote of Kent Beck. What he was proposing was fine and then over time people became clearly unreasonable.
https://registerspill.thorstenball.com/p/a-few-words-on-testing
Tags: tech, programming, productivity
Very interesting piece. The DORA metrics are a good thing but I always felt they’re kind of dry and missing something. On the other hand surveys which are more qualitative give also interesting results but come with their own biases. The idea pushed here for better qualitative surveys and to combine them with quantitative metrics like the DORA one is definitely a tempting way forward.
https://martinfowler.com/articles/measuring-developer-productivity-humans.html
Tags: history, evolution
Very interesting theory on why the nautiloids started disappearing. A specie developed lips…
https://crookedtimber.org/2024/03/16/occasional-paper-when-armor-met-lips/
Bye for now!
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.
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.
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.
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.
/etc/xdg/kdeglobals
[KDE Action Restrictions][$i]
ghns=false
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? 
Declarative effects require some particular project structure that we need to learn first before writing any code
└── package
├── contents
│ └── ui
│ └── main.qml
└── metadata.json
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.
{
"KPackageStructure": "KWin/Effect",
"KPlugin": {
"Authors": [
{
"Email": "user@example.com",
"Name": "Name"
}
],
"Category": "Appearance",
"Description": "Yo",
"EnabledByDefault": false,
"Id": "hello-world",
"License": "MIT",
"Name": "Hello World"
},
"X-KDE-Ordering": 60,
"X-Plasma-API": "declarativescript"
}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
kpackagetool6 --type KWin/Effect --install package/
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.
Let’s start with an effect that simply shows a hello world message on the screen:
import QtQuick
import org.kde.kwin
SceneEffect {
id: effect
delegate: Rectangle {
color: "blue"
Text {
anchors.centerIn: parent
color: "white"
text: "Hello world!"
}
}
ScreenEdgeHandler {
enabled: true
edge: ScreenEdgeHandler.TopEdge
onActivated: effect.visible = !effect.visible
}
ShortcutHandler {
name: "Toggle Hello World Effect"
text: "Toggle Hello World Effect"
sequence: "Meta+H"
onActivated: effect.visible = !effect.visible
}
PinchGestureHandler {
direction: PinchGestureHandler.Direction.Contracting
fingerCount: 3
onActivated: effect.visible = !effect.visible
}
}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.
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
delegate: Rectangle {
color: "blue"
WindowThumbnail {
anchors.centerIn: parent
client: Workspace.activeWindow
}
}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 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
delegate: Rectangle {
color: "pink"
GridView {
id: grid
anchors.fill: parent
cellWidth: 300
cellHeight: 300
model: WindowModel {}
delegate: WindowThumbnail {
client: model.window
width: grid.cellWidth
height: grid.cellHeight
TapHandler {
acceptedButtons: Qt.MiddleButton
onTapped: client.closeWindow()
}
}
}
}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
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.
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.
package/
├── contents
│ ├── config
│ │ └── main.xml
│ └── ui
│ └── main.qml
└── metadata.json
The main.xml file lists all options
<?xml version="1.0" encoding="UTF-8"?>
<kcfg xmlns="http://www.kde.org/standards/kcfg/1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.kde.org/standards/kcfg/1.0
http://www.kde.org/standards/kcfg/1.0/kcfg.xsd" >
<kcfgfile name=""/>
<group name="">
<entry name="BackgroundColor" type="Color">
<default>#ff00ff</default>
</entry>
</group>
</kcfg>
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
delegate: Rectangle {
color: effect.configuration.BackgroundColor
Text {
anchors.centerIn: parent
color: "white"
text: "Hello world!"
}
}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
package/
├── contents
│ ├── config
│ │ └── main.xml
│ └── ui
│ ├── config.ui
│ └── main.qml
└── metadata.json
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
<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
<class>QuickEffectConfig</class>
<widget class="QWidget" name="QuickEffectConfig">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
<width>455</width>
<height>177</height>
</rect>
</property>
<layout class="QFormLayout" name="formLayout">
<item row="0" column="0">
<widget class="QLabel" name="label">
<property name="text">
<string>Background color:</string>
</property>
</widget>
</item>
<item row="0" column="1">
<widget class="KColorButton" name="kcfg_BackgroundColor">
<property name="flat">
<bool>false</bool>
</property>
</widget>
</item>
</layout>
</widget>
<customwidgets>
<customwidget>
<class>KColorButton</class>
<extends>QPushButton</extends>
<header>kcolorbutton.h</header>
</customwidget>
</customwidgets>
<resources/>
<connections/>
</ui>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
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 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/.
Besides the link above, it’s worth having a look at the examples https://invent.kde.org/plasma/kwin/-/tree/master/examples?ref_type=heads in kwin git repository.
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.
The WindowHeap source code can be found at https://invent.kde.org/plasma/kwin/-/tree/2a13a330404c8d8a95f6264512aa06b0a560f55b/src/plugins/private.
If you need more examples, I suggest to have a look at the desktop cube effect in kdeplasma-addons. It’s implemented using the same QML effect API in kwin + QtQuick3D. The source code can be found at https://invent.kde.org/plasma/kdeplasma-addons/-/tree/master/kwin/effects/cube?ref_type=heads
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.
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.
Clear the text editor and enter the following:
@nathanu:matrix.orglet 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.”
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:
qdbus org.kde.plasmashell /PlasmaShell evaluateScript ''and between those single-quote marks, paste in the full script we put together in the Desktop Shell Scripting Console, like this:
qdbus org.kde.plasmashell /PlasmaShell evaluateScript 'let panel = panelById(401);
panel.hiding === "autohide" ? panel.hiding = "windowsgobelow" : panel.hiding = "autohide";'
Set up a tooltip if you like, hit apply, and test out your toggle button.
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.
Thanks to all the contributors. They fixed bugs, wrote documentation, modernized the code, and in general took care of Kile.
Enjoy the latest Kile release!
Dear digiKam fans and users,
After four months of active maintenance and long bugs triage, the digiKam team is proud to present version 8.3.0 of its open source digital photo manager.
This version arrives with the internal RAW decoder Libraw updated to the rolling-release snapshot 2024-02-02. Long time bugs present in older versions have been fixed and we spare a lot of time to contact users to validate changes in pre-release to confirm fixes before deploying the program in production.
