Planet KDE

It’s high tension in Neon towers this week as the distro packagers have been given access to the source tars for Plasma 6 along with Frameworks 6 and KDE Gear 24.02. This means our cloud of build servers have been powered up to compile them into .deb packages which go into our Apt archive. In principle we already have the packaging working in Unstable and Testing edition so it should be a case of just doing a fresh build in User edition but it involves several hundred source builds all done for the three editions and for libraries and plugins (such as KIO Workers) many of them twice over, once for Qt 6 and once for Qt 5 builds. So lots of bits which need aligned. Frameworks completed yesterday morning and this morning it looks like all of Plasma is built. The KDE Gear apps are churning away now. We’ll then need to tests it all including many configurations of upgrade to make sure it doesn’t break your laptops. The releases are due on Wednesday and with any luck we will have Neon builds available very shortly after, but of course we’ll wait until it’s ready if that’s what we have to do. It’ll be just a normal upgrade available to Discover but of course with a large number of packages to download. Who’s excited?

Just in time for KDE Plasma 6, Chromium 122 and Electron 29 have been released! They contain my patch that adds support for Wayland’s new cursor-shape-v1 extension protocol. When running natively in a Plasma 6 Wayland session, up-to-date Chromium-based browsers and Electron apps should now always use the correct mouse cursor theme and have the...

The post cursor-shape-v1 in Chromium and Electron first appeared on Ilya's Blog.

It’s time for another foss-north again and the Call for Papers is open (as is the Call for Sponsors, hint, hint, nudge, nudge). Make sure to save the dates (April 15-16), get yourself a ticket, and submit your talk!

Happy weekend!

It has been a very busy 3 weeks here in Kubuntu!

Kubuntu 22.04.4 LTS has been released and can be downloaded from here: https://kubuntu.org/getkubuntu/

Work done for the upcoming 24.04 LTS release:

• Frameworks 5.115 is in proposed waiting for the Qt transition to complete.
• Debian merges for Plasma 5.27.10 are done, and I have confirmed there will be another bugfix release on March 6th.
• Applications 23.08.5 is being worked on right now.
• Added support for riscv64 hardware.
• Bug triaging and several fixes!
• I am working on Kubuntu branded Plasma-Welcome, Orca support and much more!
• Aaron and the Kfocus team has been doing some amazing work getting Calamares perfected for release! Thank you!
• Rick has been working hard on revamping kubuntu.org, stay tuned! Thank you!
• I have added several more apparmor profiles for packages affected by https://bugs.launchpad.net/ubuntu/+source/kgeotag/+bug/2046844
• I have aligned our meta package to adhere to https://community.kde.org/Distributions/Packaging_Recommendations and will continue to apply the rest of the fixes suggested there. Thanks for the tip Nate!

We have a branding contest! Please do enter, there are some exciting prizes https://kubuntu.org/news/kubuntu-graphic-design-contest/

Debian:

I have uploaded to NEW the following packages:

• kde-inotify-survey
• plank-player
• aura-browser

I am currently working on:

• alligator
• xwaylandvideobridge

KDE Snaps:

KDE applications 23.08.5 have been uploaded to Candidate channel, testing help welcome. https://snapcraft.io/search?q=KDE I have also working on bug fixes, time allowing.

My continued employment depends on you, please consider a donation! https://kubuntu.org/donate/

Thank you for stopping by!

~Scarlett

Two weeks ago I showed a screenshot of initial support for the MOTIS routing engine in KTrip in my FOSDEM 2024 report. Driven by the Transitous work this is meanwhile nearing completion and will ship with the 24.05 release.

KDE’s apps consuming public transport data such as KTrip or Itinerary are built on top of the KPublicTransport library, which abstracts various different protocols and services providing that data.

As questions about adding new backends have been coming up recently, I tried to improve documentation, developer convenience and common infrastructure while adding the MOTIS support:

• KPublicTransport::AbstractBackend now has more documentation especially about the not so obvious aspects like paging support.
• Backend configuration files can now also be loaded from $XDG_DATA_DIRS/org.kde.kpublictransport/networks rather than just from the compiled-in QRC data. By symlinking the corresponding source directory you can therefore see the effect of modifications without recompiling. This also allows having configurations for e.g. the public MOTIS demo instance or a local one in the repository without those being visible to users.
• Improved the built-in infrastructure for paging through arrival query results, to the point where this now also works for subsequent arrivals with backends not having any native paging support.

When it comes to MOTIS support, almost every feature of MOTIS’ API that is modelled in KPublicTransport has been implemented:

• Station queries by name or coordinate.
• Arrival and departure queries for a given station, including paging in all combinations.
• Journey searches between a specific station and/or a coordinate, with paging support.
• When search to/from a coordinate, intermodal routing is used, supporting the following options:
  • Walking
  • Biking
  • Taking a car
  • Taking a car to an available parking space and then walking to the station

A few things still remain to be done:

• Intermodal routing using shared scooters/bikes etc.
• Retrieving routing paths for intermodal journey sections.

And there’s a few more very interesting features in MOTIS that we’d like to support eventually but that are currently not yet represented in the KPublicTransport API:

• “ontrip” journey queries, that is starting not at a fixed location but on a train or bus already, finding the best route to a destination given the current realtime situation (which can change along the way).
• Retrieving the realtime status of parking spaces. While in Germany that is always synonymous with car parking, the excellent bike parking infrastructure in the Netherlands in some places apparently also has API for the amount of currently available parking spots.
• Support for routing profiles for walking sections. That is things like walking speed or your willingness or ability to deal with steps/stairs, steep elevation, etc.

One thing that made the work on the MOTIS support somewhat unique is that this is the first KPublicTransport backend for which I had a fully functional local server setup, and one where I could debug and modify things even.

This allowed identifying a nasty API issues and subsequently getting that fixed, fixing a bug in location queries and even adding a missing feature. Ie. finally working the way we are used to in the Free Software world.

The wishlist for MOTIS has been growing over the past weeks as well, so there’s more to do here. MOTIS has a very strong focus on the routing algorithms, and their performance and optimality guarantees (ie. the hard part), but only exposes the bare minimum of information not relevant for routing in its API. From a client and UX perspective we’d like to get all details that could possible be important for users from the GTFS or GBFS source data though.

According to MOTIS’ Github stats two out of its top 10 contributors are meanwhile from KDE, so we’ll probably get all that eventually :)

All of this work is motivated by the ongoing effort to set up a MOTIS instance for a free and open public transport routing service, which is continuing at a rapid pace. If that succeeds we’d be able to bring public transport routing coverage also to some areas where our apps are currently useless.

As I’m writing this I’m on the way to the upcoming OSM Hack Weekend in Karlsruhe, where I hope to discuss some of the challenges we encountered with scaling up the OSM-based first/last mile routing in MOTIS. More on that hopefully next week then.

A new version of Kirigami Addons is out! Kirigami Addons is a collection of helpful components for your QML and Kirigami applications. With the 1.0 release, we are now supporting Qt6 and KF6 and added a bunch of new components and fixed various accessibility issues.

We added a bunch of new FormCard delegates:

• FormPasswordFieldDelegate: A password field
• FormDataTimeDelegate: A date and/or time delegate with integrated date and time picker which use the native picker of the platform if available (currently only on Android).

Form card example

The existing delegates also recevied various accessibility issues when used with a screen reader.

Finally we droped the compatibility alias MobileForm.

Mathis added a new Drawer component that can be used a context menu or to display some information on mobile.

Bottom Drawer in Itinerary showing the information about a station on the map

These two components received significant sizing and consistency improvements which should improve their touch area on mobile.

You can find the package on download.kde.org and it has been signed with my GPG key.

Oxygen Icons is an icon theme for use with any XDG compliant app and desktop.

It is part of KDE Frameworks 6 but is now released independently to save on resources.

This 6.0.0 release requires to be built with extra-cmake-modules from KF 6 which is not yet released, distros may want to wait until next week before building it.

Distros which ship this version can drop the version released as part of KDE Frameworks 5.

sha256: 28ec182875dcc15d9278f45ced11026aa392476f1f454871b9e2c837008e5774

URL: https://download.kde.org/stable/oxygen-icons/

Signed by E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell <[email protected]>
https://jriddell.org/esk-riddell.gpg

This project is creating a WS-Discovery client library based on the KDSoap library.

The name is short for Klarälvdalens Datakonsult AB Simple Object Access Protocol Web Services Addressing Discovery Client.

It is used by the SMB KIO worker from kio-extras.

kio-extras will have two releases as part of KDE’s 6th Megarelease, one for Qt 5 and one for Qt 6. Distros should build and ship both versions of kio-extras but the Qt5 build should use the internal static copy of kdsoap-ws-discovery-client so does not need to be built separately. The Qt 6 build of kio-extras does need this external build of kdsoap-ws-discovery-client. Distros will need an up to date copy of KDSoap library.

There are no changes compared to 0.3.0 but this one is released as stable ahead of KDE Gear 24.02.

SHA 256: 2cd247c013e75f410659bac372aff93d22d71c5a54c059e137b9444af8b3427a
URL: https://download.kde.org/stable/kdsoap-ws-discovery-client/
Signed by E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell <[email protected]>
https://jriddell.org/esk-riddell.gpg

The Plasma Mobile team is happy to announce the release of Plasma 6 for mobile devices!

It has been a long year of development and porting since our last major release of the shell, as well as mobile applications. This post will outline many of the highlights!

The website was refreshed in anticipation for this release. Notably, the installation page was enhanced to better outline information about the various distributions that provide Plasma Mobile.

During the Plasma 6 development period, postmarketOS graciously provided us with a "nightly" repository of KDE packages tracking git repositories. We have found this critically useful for development. You can find instructions on how to use this repository here.

Devin wrote a blog post covering some technical details covering the big aspect of the work porting all of the shell components to Qt and Plasma 6 APIs. A lot of functional work was done as well.

With Plasma 6, we are once again switching back to the Folio homescreen as default. The homescreen will once again have customizable pages to place apps and widgets, as well as an app drawer and search. Devin spent time rewriting it from scratch, addressing the limitations that existed in Plasma 5, in particular the customizations are now tied to each page, no longer causing reordering issues from screen rotations.

Notable Features:

• Customizable pages to place apps and widgets
• Folders
• Drag and drop customization
• Widgets (still some known issues, see below)
• App drawer (swipe up)
• KRunner search (swipe down)
• Row-column flipping for screen rotations
• Customizable row and column counts
• Customizable page transitions
• Import and exporting of homescreen layouts as files
• and more!

In Plasma 5, Plasma Mobile required several config files to be installed on the system in order to set some settings needed in Plasma. For Plasma 6, Devin created a new settings service that automatically handles this situation. This allows for interoperability with Plasma Desktop being simultaneously installed on the system, and eliminates the need to install custom configuration.

Devin added an initial setup window that guides users to configure some basic aspects of the system, such as Wi-Fi and cellular settings.

Devin worked on porting the authentication dialog so that it has a mobile form factor.

Devin worked on adding a "docked mode" quicksetting which, when activated, enables window decorations and minimize/maximize/close buttons, and also stops enforcing application windows to be in fullscreen.

Devin added a setting to always show the keyboard toggle button. He also made it so that if there is enough screen space, the panel goes on the bottom for tablets rather than on the side.

The task switcher was moved from the Plasma shell and into KWin to improve code maintainability.

In Plasma 5, the default vibration speed was hardcoded to the PinePhone's motor, which could not register lower vibration durations. This resulted in other devices having overly strong vibration effects. Vibrations now default to an acceptable level for other devices, and can still be configured in the shell settings module.

The flashlight quicksetting in Plasma 5 is hardcoded to the PinePhone. Florian worked on making it so that it now works with all phones in Plasma 6!

Devin improved the cellular settings module so that interaction tasks are asynchronous and do not freeze the UI. He also fixed unnecessary password prompts from being shown when the module is first opened.

Devin ported the Wi-Fi settings module to mobile form components, making it consistent with other modules. He overhauled the time settings module to newer components as well, making setting the time and date more intuitive. He also did some work to ensure the UI does not freeze when applying settings.

Joshua refactored the look and feel of the Push Notifications KCM and added UnifiedPush support to NeoChat so you'll never miss a message, even when NeoChat is closed (that is, if you want to get notifications, of course!)

Mathis created a new icon for the application.

Regrettably, our team resources are limited, and so we still have several outstanding issues that were not addressed in time for this release:

• Scrolling in Qt6 with a touchscreen has very low inertia compared to Qt5 and we cannot change the platform default, see this, reported in upstream to Qt here
• Some homescreen widgets open popups every time they are moved around
• Limited widget selection. Currently we just have existing widgets from the Plasma Desktop
• The screen recording quicksetting was removed for the time being. It needs further investigation on porting it to new APIs
• Gesture-only mode was removed for the time being. We need to investigate making KWin's gesture infrastructure fit our needs
• Sometimes application windows extend under the navigation bar. We need to investigate this regression with KWin
• The task switcher is slow on the PinePhone in particular. We need to investigate the performance of the KWin effect

There are other issues also being tracked in our issue tracker.

A tremendous amount of work went into the massive effort behind porting all of our applications to Qt6 and KF6. We would like to extend a big thank you to everyone involved!

Many major announcements for applications are in the Megarelease post, so be sure to check there too!

While the application is still called Koko, user-facing text now calls it "Photos" to make it easier for you to find. (Devin Lin, KDE Gear 24.02, Link)

A new icon was created for the application, replacing the gorilla (Mathis Brüchert & Devin Lin, KDE Gear 24.02, Link)

The Clock app now pauses MPRIS media sources when an alarm or timer starts ringing and resumes (previously paused) sources once the alarm is dismissed (Luis Büchi, KDE Gear 24.02, Link)

A new configuration page was added to the calculator app, allowing to set decimal places, angle units and a parsing mode (Michael Lang, KDE Gear 24.02, Link)

We improved the history view to allow for the removal of entries, and the drawer-style area for extra functions got replaced with a swipe view (Michael Lang, KDE Gear 24.02, Link 1, Link 2)

A number of new features and QoL improvements were added, including automatic font resizing when entering long expressions, better rendering of exponents, and more actual calculation features: random number, base n root/log, differential functions, standard deviations, and a lot more... Oh! and we switched math the engine to libqalculate! (Michael Lang, KDE Gear 24.02, Link 1, Link 2, Link 3, Link 4)

Apart from some minor visual changes related to the Qt6 and KF6 update and several fixes regarding images and playback controls, Kasts will now update podcasts dramatically faster by not parsing RSS feeds that haven't changed (Bart De Vries, KDE Gear 24.02 Link 1)

The color theme (e.g. Breeze light, Breeze dark) can now be selected manually (Bart De Vries, KDE Gear 24.02 Link 2)

Network checks for metered connections can now be disabled altogether. This can be useful on systems that are not able to reliably report the connection status (Bart De Vries, KDE Gear 24.02 Link 3)

Do you want to help with the development of Plasma Mobile? We are a group of volunteers doing this in our free time, and are desperately looking for new contributors, beginners are always welcome!

See our community page to get in touch!

We are always happy to get more helping hands, no matter what you want to do, but we especially need support in these areas:

• Telephony

• Camera support

• You can also check out our Plasma Mobile issue tracker for more details.

Even if you do not have a compatible phone or tablet, you can also help us out with application development, as you can easily do that from a desktop!

Of course, you can also help with other things besides coding! For example, take Plasma Mobile for a spin to help us test bugs and triage reports! Check out the device support for each distribution and find the version which will work on your phone.

Another option would be to help us in making these blog posts more regular again. We really don't want another 6 months of silence, but writing these take a surprising amount of time and effort.

If you have any further questions, view our documentation, and consider joining our Matrix channel. Let us know what you would like to work on or where you need support to get going!

Our issue tracker documentation also gives information on how and where to report issues.

We would like to thank all of the contributors across KDE that have made this megarelease possible! We could not have done it without you. Thank you!

KdeEcoTest is an emulation tool aimed at emulating user activity when measuring the energy consumption of an application. You can read more about work on KdeEcoTest at this SoK23 and this SoK24 blog post. Check out the KDE Eco handbook for more details about measuring software's energy consumption.

Figure : KDE Eco logo.

One of the main goals of the KDE Eco project for Season of KDE 2024 is to extend KdeEcoTest so it can run on both Windows and GNU/Linux (X11 & Wayland). This enables energy consumption measurements of a single application across different platforms, such as Okular in X11 vs. Wayland vs. Windows.

This also makes it possible to compare Okular with a proprietary application like Adobe Acrobat. Comparisons with proprietary software are possible because KdeEcoTest can create usage scenario scripts without requiring access to the source code of the software being tested!

I have taken the task of extending support for Windows.

The primary function of KdeEcoTest is to emulate user behavior. Why do we need an abstraction layer for this?

1. Think about simulating keyboard shortcuts. We'll need to change many parts of the code. But if we have an abstraction layer, we can add new features easily. Just add a function to the right module.
2. Currently, we have 3 modules for 3 different platforms, namely, Wayland, X11, and Windows. If a fourth platform needs to be added, one can simply extend the base handler class and implement the abstract functions.
3. This abstraction layer ensures that the same script can be used for testing across several different platforms.

During the first two weeks of SoK'24, Athul Raj K and I worked on understanding the code base and creating the abstraction layer. The layer provides two interfaces to access the underlying methods for taking window or input actions, a WindowHandler and an InputHandler (which have platform specific implementations).

Figure : Running a Standard Usage Scenario script on the Windows Platform for GCompris prepared with KdeEcoTest.

pywin32 is a python module that provides access to many of the Windows APIs. This is used to perform window management actions for the Windows platform. Special thanks to Emmanuel for pointing out this wonderful module which has made it very convenient to extend KdeEcoTest support to Windows.

Win32 is an application programming interface (API) developed by Microsoft. It is dedicated to 32-bit Windows operating systems. Using this API, developers benefit from a set of functions for creating Windows applications using programming languages such as C, C++, and Visual Basic. They are able to control and manipulate various aspects of the Windows operating system. ctypes is a Python library for calling functions from shared libraries (DLLs) with a syntax similar to C. Pywin32 uses ctypes to use win32 functions.

During the first week, I explored the module to find the required functions and tested them out on a Windows machine. In the third week of Sok'24, I integrated the functions in the KdeEcoTest codebase. Now, the same test scripts that were used to test on X11 also run on Windows! The WindowActionHandler of win32 module under core/Handlers/win32.py handles the window management functions for Windows platforms.

pywin32 also provides support for simulating mouse actions such as left clicks as well as keyboard key presses. However, I am not yet able to create a proper listener for input actions of the user. The module does not provide a default listener, although it does provide a function win32api.GetAsyncKeyState() which can be used as a listener inside an infinite loop. Running an infinite while-loop results in unnecessary resource utilization of processor and main memory, which slows down the tool and affects the results of the test cases.

For these reasons, pynput has been chosen instead, which works across all the targeted platforms.

The class InputActionHandler bundles all the pynput handlers required for emulating the user input activities

Currently, I am working on testing the accuracy of mouse pointers using the 9 point calibration testing. This can also be used to check window size inaccuracy caused by window decorations such as the title bar on Windows.

I also plan to replace pynput with pywin32 if I can find or develop a proper listener for user actions.

I would like to thank the project mentors Emmanuel Charrau and Joseph P. De Veaugh-Geiss for their amazing support and guidance. Also, I am thankful to Athul Raj K, my fellow contributor in SoK'24, for his support and collaboration during this Season of KDE.

We’re thrilled to unveil an extraordinary opportunity for creatives and enthusiasts within and beyond the Kubuntu community

The Kubuntu Graphic Design Contest.

This competition invites talented designers to play a pivotal role in shaping the next generation of the Kubuntu brand. It’s your chance to leave a lasting mark on one of the most beloved Linux distributions in the world.

The contest centers on reimagining and modernizing the Kubuntu brand, including the logo, colour palette, fonts, and the default desktop environment for the upcoming Kubuntu 24.04 release. We’re seeking innovative designs that reflect the essence of Kubuntu while resonating with both current users and newcomers.

Guidelines:

Inspiration: Contestants are encouraged to review the current brand and styles of kubuntu.org, kde.org, and ubuntu.com to understand the foundational elements of our visual identity.

Creativity and Modernity: Your submission should propose a fresh, modern look and feel for the Kubuntu brand and its supporting marketing materials. Think outside the box to create something truly unique.

Cohesion: While innovation is key, entries should maintain a cohesive relationship with the broader KDE and Ubuntu ecosystems, ensuring a seamless user experience across platforms.

How to Participate:

The contest is open now! We welcome designers from all backgrounds to contribute their vision for Kubuntu’s future.

Multiple entries are allowed, giving you ample opportunity to showcase your creativity.

Submission Deadline: All entries must be submitted by 23:59 on Sunday, 31st March.

Prizes:

Winner will have the honour of seeing their design become the face of Kubuntu 24.04, receiving recognition across our platforms and within the global open-source community.

First Prize:

• Global recognition of your design as the new face of Kubuntu.
• A trophy and certificate.
• A Kubuntu LTS optimized and validated computer: the Kubuntu Focus Ir14 Laptop or the Kubuntu Focus NX MiniPC with 32 GB of RAM – over a $1,000 value.
• Kubuntu Focus branded merchandise up to $50 USD shipped.

Second Prize:

• Your runner up entry featured on kubuntu.org.
• A trophy and certificate.
• Kubuntu Focus branded merchandise up to $50 USD shipped.

Third Prize:

• A trophy and certificate.
• Kubuntu Focus branded merchandise up to $50 USD shipped.

This is more than a competition; it’s a chance to contribute to a project that powers the computers of millions around the world. Whether you’re a seasoned designer or a passionate amateur, we invite you to bring your vision to life and help define the future of Kubuntu.

For more details on how to submit your designs and contest rules, visit our contest page.

Let’s create something extraordinary together. Your design could be the next symbol of Kubuntu’s innovation and community spirit.

KdeEcoTest is an automation and testing tool which allows one to record and simulate user interactions with a Graphical User Interface. It is being developed as part of the FOSS Energy Efficiency Project to create usage scenario scripts for measuring the energy consumption of software in the KDE Eco initiative. Emmanuel Charruau is the original developer and lead maintainer of the project. In Season of KDE 2023 the tool was further improved by Mohamed Ibrahim under the tutelage of Karanjot Singh and Emmanuel Charruau.

One of the main goals in Season of KDE 2024 is to make the KdeEcoTest cross-platform so it can run on Windows and Linux systems (both Wayland and X11). Another necessary change in KdeEcoTest is to completely remove the use of libX11 and xdotool from the code base, which had issues with pixel coordinates while testing.

A benefit of a tool such as KdeEcoTest is that it is possible to create usage scenario scripts without having access to the source code of the software being tested. This is in contrast to a tool such as Selenium-AT-SPI, which requires access to the application's sources (QML file).

See how Selenium-AT-SPI helps with the KDE Eco project (Selenium-AT-SPI KDE Eco).

For the tool to be cross platform, it requires a platform abstraction layer, which is what Amartya Chakraborty and I, the SoK24 team, set out to write first. Any action, either simulated or read by the KdeEcoTest tool, can be separated into Window-based and Input device-based. The design goal is therefore to provide platform-independent interfaces for performing these actions.

We finished work on the abstraction layer and integrated it into the current code base with some minor changes. The layer provides two interfaces, a WindowHandler and an InputHandler (which have a platform-specific implementation), in order to access the underlying methods for taking window or input actions.

The team's next task was to implement these platform-specific classes. For the SoK24 project, Windows-specific classes were tasked to Amartya Chakraborty, while I set out to implement support for Wayland.

From initial conversations between me, Emmanuel, and other members of the KdeEcoTest channel, we decided on using ydotool, a program written in C that simulates input devices with uinput. This enables the simulation of input devices on Wayland as well.

But ydotool was not enough as it did not support manipulating windows like xdotool did and we still required listening to input devices. For Window-based actions it requires communication with the underlying display server or compositor (in Wayland world), and Wayland currently did not have such a protocol. So we went back to the drawing board and tried different methods, even running the application as an X Client on Xwayland, which indeed worked but could hardly be called a solution to supporting Wayland.

Figure : Running as X client on Wayland using Xwayland. (Image from Wayland docs published under an MIT license.)

We thought that currently there did not exist any solution for Wayland, but we were wrong. It turns out that KWin, the KDE Plasma compositor for Wayland and X11, already had one! One fine day Emmanuel posted a message on the KDE Dev channel, and voilà we got our solution from a KDE developer in the form of a Rust tool, kdotool. The tool uses KWin’s dbus interface to upload a JavaScript file and access methods and properties provided by the KWin scripting API. Just love you, KDE!

Emmanuel brought kdotool’s author ‘genericity’ on board and we set sail. With some minor tweaks and upgrades we integrated kdotool into KdeEcoTest and we now have all window-related functionalities set up and working on X11 and Wayland. (Oh … and by the way that’s when I found out you can’t have gitsubmodules on invent.kde.org). The use of the KWin specific APIs means that KdeEcoTest will currently only work on KDE Plasma.

Special mention to ‘genericity’ for developing this great tool.

With all window-related actions in, it was time to add support for input actions. I was testing this out with ydotool, but later dropped it and decided to directly access uinput. Reading through Linux kernel documentation, I found it's rather better to use the evdev interface, which also allows one to create and simulate devices and also to read inputs from existing ones.

evdev is the generic input event interface. It passes the events generated in the kernel straight to the program, with timestamps. The event codes are the same on all architectures and are hardware independent. The layout of the input event -

time is the timestamp, it returns the time at which the event happened. Type is for example EV_REL for relative movement, EV_KEY for a keypress or release. code is event code, for example REL_X or KEY_BACKSPACE. value is the value the event carries. Either a relative change for EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for release, 1 for keypress and 2 for autorepeat.

You can find more details about the input event codes here, https://docs.kernel.org/input/event-codes.html.

libevdev sits below the process that handles input events, in between the kernel and that process. The stack would look like this:

• Kernel → libevdev → libinput → Wayland compositor → Wayland client

And for X11 using libinput:

• Kernel → libevdev → libinput → xf86-input-libinput → X server → X client

With the python-evdev binding for libevdev one could directly access evdev devices, but there is a catch: the script needs to be run as root, or the user needs permissions to read and write from /dev/input and /dev/uinput (and also /dev/console to run dumpkeys to get the keyboard drivers translation table). Considering the challenges, this was something we could live with.

My first plan was to directly use evdev to simulate and listen to input devices, but digging into it some more I found out that pynput had a uinput backend that, it turns out, was not fully implemented (it was partially implemented for keyboard). pynput is a cross-platform Python library that allows one to control and monitor input devices. Since pynput was already being used in KdeEcoTest and it supported all other systems (except Wayland), implementing a backend that uses libevdev would allow for using pynput and its already implemented methods and classes directly.

I finished writing a backend for pynput which allowed me to simulate and listen for mouse and keyboard events on Wayland. But there is one more problem with directly using libevdev. Input events generated from libevdev are passed to libinput before reaching the compositor.

Figure : libinput (Image from Wayland docs published under an MIT license.)

libinput processes these inputs and provides easy-to-use APIs to handle them. It also provides configurable interfaces, which means that inputs we simulate using uinput may not be interpreted the same way by the compositor. For, e.g. the delta values in EV_REL type events (Event type for relative movement) generated by evdev devices such as a mouse are converted into relative movement on screen using a function called pointer accelaration in libinput. This function depends on the pointer acceleration profiles configured by the user depending on the compositor. There are namely two: "adaptive and flat". We skip further low level details about this here, and just add that switching to "flat" profile provides 1:1 movement between the device and the pointer on-screen. This also means that the mouse acceleration profile needs to be set to flat when running KdeEcoTest.

Now all that was required was to alias InputHandler class's attributes to pynput classes. This may be improved in the future when individual level implementation is required.

With both now implemented and integrated, KdeEcoTest supports running on Wayland, and also with the contribution from Amartya Chakraborty it runs on Windows as well.

The platform abstraction layer in current form sets the required backend for pynput, imports the necessary backend and exposes the required interfaces WindowHandler and InputHandler. When running on KDE Plasma, since we require kdotool, it additionally adds kdotool to the path.

The listener for mouse events in pynput's uinput backend currently does not listen for touchpad events, because the event codes generated made it confusing to implement one. I think a better approach would be to use libinput for listening for events, as this would provide abstraction and also make it easier to write code for handling events, but libinput currently lacks a python binding.

Of course it is far from complete. KdeEcoTest is still very much a work in progress and we're happy to have more developers looking to contribute. Hop on to the KdeEco and KdeEcoTest matrix channels to join the developers and follow the tool's development.

See https://invent.kde.org/teams/eco/feep for the FEEP repository, which hosts the KdeEcoTest tool among others.

Thank you to Emmanuel, 'genericity', Amartya, Joseph, as well as the whole KDE community and Wayland developers for helping out with the project.

The post Kdenlive 23.08.5 released appeared first on Kdenlive.

Some time ago, Marco started a series of articles on SObjectizer. It is starting to become the source for all things SObjectizer – it is currently at post number 19 – quite an endeavour.

For those who haven’t met SObjectizer before, it is a framework for writing concurrent applications which supports the actor model, publish-subscribe…

EDIT: The series are available on Marco’s blog as well as on dev.to