Plasma Settings gained the ability to show all settings modules (for all platforms, such as desktop) under a toggle. It now supports the ability to show an "Apply" button for settings modules that do not want settings to save automatically. The header being misaligned on category pages is now fixed.
Please note: most Plasma Mobile software is now shipped under the Plasma or KDE Gearrelease cycles.
Today, I am announcing a new release of Plasma Camera, a camera application for Plasma Mobile (though it can also be used on desktop!). This release ports the application to use libcamera as the backend for interfacing with cameras, finally allowing for it to be used on Linux mobile devices (such as the OnePlus 6).
The main porting work was done by my friend Andrew (koitu) a couple of months ago. It remained stalled on some issues, so I picked it up in the past week to complete the port and finish the application. Here is a link, which has more technical details!
Cameras have been a long neglected area in Plasma Mobile, ever since the focus shifted from halium to mainline devices. With mainline devices, libcamera drivers have been developed for them, allowing for cameras to be used in applications over Pipewire (ex. GNOME Snapshot, Firefox, Chromium).
Plasma Camera was originally created in 2019 with halium devices in mind, using the official Qt Camera library as a backend for interfacing with cameras. This library allows for the app to work on Android and on desktop with USB webcams. Unfortunately, Qt Camera does not currently have support for using Pipewire or libcamera directly as a backend, and so is unable to interface with the cameras on the OnePlus 6 and Pixel 3a.
Qt Camera is a fairly high-level API designed to abstract over many different platforms, beyond Linux. Since our focus is on Linux, we decided to take this chance to port Plasma Camera to use libcamera directly for best control over the camera pipeline and features. Note that this approach differs from some other camera applications that use Pipewire, which has a backend to communicate with libcamera.
In order to implement the viewfinder (camera preview), we create a worker thread that is responsible for polling the camera for frames. A series of “requests” with a framebuffers allocated to each were created, which we cycle through when polling for frames. Libcamera then gives us a frame for each poll request, in which we send to our application thread to display.
For simplicity, Qt Multimedia was used for media processing. Frames from libcamera are wrapped in QImages and sent to a QVideoSink to be displayed in the UI. Any transformations needed (such as rotation correction due to how sensors are mounted on phones, or mirroring for front-facing cameras) are done before the frame is added to the sink. For taking photos and videos, we reuse the viewfinder’s frames.
For photos, we simply write the QImage to the disk.
Videos are much more tricky. Using Qt Multimedia we can build a video processing pipeline. We create a QMediaCaptureSession to facilitate all of the inputs and outputs needed. We then attach a media recorder QMediaRecorder for writing the video, an audio input (QAudioInput) and a video input (QVideoFrameInput). We have a separate polling timer that polls at the framerate of the video (which can differ from the framerate of the viewfinder), copying frames one-by-one into the QVideoFrameInput instance (more on this later) to be encoded by QMediaRecorder.
In the future, it may make sense to investigate whether we could benefit from porting to using GStreamer directly for media processing. We currently use Qt Multimedia with its ffmpeg backend. While Qt Multimedia does have an gstreamer backend, it has some limitations and was thus removed from being the default backend as a result.
I also took the liberty of doing some substantial refactoring and reworking of the UI code. We dropped some camera settings for the initial port of the application, to be restored later. However some other features were introduced.
The application has these features:
Photo capture
Video capture
Audio recording toggle for video capture
EV setting (exposure value)
Captured photo/video preview
Video recording settings (codec, resolution, FPS, quality)
Timer before taking a photo
Warnings for when the encoder is detected to not be keeping up with the video stream
With USB webcams, both photo capture and video recording work.
It also sort of works on phones. I tested on the OnePlus 6 and Pixel 3a. I suspect that most of the issues are simply due to the camera driver not yet being mature enough, as I can replicate most of the issues on other camera applications. The photo quality and colours are not optimal, and there appears to be a fixed focal length, and so far away things look blurry.
The viewfinder stream is fine on my OnePlus 6 and looks smooth. However, for my Pixel 3a, the frames start flashing light and dark colours when I point the camera at any bright light source. I suspect it is due to the camera driver overcompensating for exposure perhaps? Not sure 😅
Photo capture works on both devices, outputting the frame from the viewfinder at full resolution to the disk almost instantly. Though the quality of the pictures is reminiscent of early 2000s phone photography.
The video recording experience however isn’t quite usable unfortunately, the video encoder does not appear to be able to keep up.
The main barrier to video recording seems to be the performance of the video encoder. I’ve noticed on both phones that many frame calls to QVideoFrameInput fail because QMediaRecorder’s queue is simply full and cannot keep up with the amount of frames coming in. This can be mitigated somewhat by playing with the video recording settings. I’ve generally found the MPEG2 codec to be substantially faster for devices, though it gives very ugly artifacting at low quality, and sometimes gives an error. Of course, lowering the resolution and FPS also can help too.
For each frame given to QVideoFrameInput, I also set its timestamp to ensure that the encoder places it at the correct place. However, when we start dropping frames due to the encoder being full, we end up with gaps in the video without a frame, which I suspect is what is causing the pixelated “corrupt video” effect (though it only happens with H264, and not MPEG2 encoding?). We cannot really queue frames for the encoder, because we would very quickly run out of memory. I have an open issue about this since I am not really sure how to address it yet.
Device rotation can be a bit of a problem with the application right now. We already account for the screen orientation in comparison to the camera orientation, which is reported as a property by libcamera.
The viewfinder however can be a problem when the display rotation is different from the screen’s orientation (ex. rotated 90, 180, 270 degrees). This is done by the compositor (ex. KWin), the application only sees that the window size has changed. However, that means the viewfinder is rotated as well! We are able to adjust for this in taken photos and video by reading the rotation sensor data (with QOrientationSensor/iio-sensor-proxy), however we cannot do the same for the viewfinder because we don’t know which orientation the compositor has the application in, which could be different from the sensor due to rotation-lock and manual settings.
I recommend keeping an orientation lock on “portrait” mode when using the application on a phone until we find a fix, that way the viewfinder does not get mismatched from what you see. We are tracking this issue here: https://invent.kde.org/plasma-mobile/plasma-camera/-/issues/14
The drivers for the OnePlus 6 and Pixel 3a seem to be missing almost all of the libcamera controls. At least, calling camera->controls() (doc) gives only the Contrast control from libcamera. There are other controls that I would like to implement once they become available, such as focus windows.
Once these are implemented in the driver (or if it’s fixed as an issue on our side) and support is added in the application, we will have a lot more camera features to play with!
We finally have a base on to use for the camera stack on Linux mobile. I hope the application continues to improve as drivers and camera support get better over time on these devices.
Kirigami Addons is a collection of supplementary components for Kirigami
applications. Version 1.9.0 is a relatively minor release, introducing two new
form delegates along with various quality-of-life enhancements.
New Features
I took over the work from Tomasz Bojczuk and finished the addition of the file and folder form delegate.
These two components wrap a FileDialog and FolderDialog respectively and like KUrlRequester in KIO provide a text field with autocompletion on desktop. Currently the autocompletion is a bit basic and is based on a Controls.TextField with a Controls.Popup, but hopefully with Qt 6.10 we can use Controls.SearchField.
Bug fixes
Outside of these two new components, this release includes minor fixes and improvements from Antonio Rojas, Nicolas Fella Soumyadeep Ghosh, Thiago Sueto, Volker Krause and Yuki Joou.
Every week we cover the highlights of what’s happening in the world of KDE Plasma and its associated apps like Discover, System Monitor, and more.
This week we continued polishing up Plasma 6.4 in response to feedback. There’s also lots of work to report improving the UI for Plasma 6.5 in a few months, as well as work on larger topics happening in the background that’s still in progress. Stay tuned!
Notable UI Improvements
Plasma 6.4.3
The automatic screen scale calculator on Wayland will no longer give you a default scale factor that’s only a little bit higher than 100%, as these scale factors often result in a lot of blurriness. Now it will instead round the calculated default scale factor down to 100% if it would otherwise be only a little bit higher. (Nate Graham, link)
Plasma 6.5.0
Screencasts of a specific window now also include any popups that the target window creates. (David Redondo, link)
Changed the Bluetooth wizard to not show unnamed devices by default. This should make the list more actionable and faster to parse. (Sebastian Kügler, link)
When you mute the system, changing the volume in any way now un-mutes all playback devices, rather than only the active one. This prevents a situation where a non-default playback device remains muted and therefore plays no sound when you switch to it deliberately, or when the system switches to it automatically for some reason. (Oliver Beard, link)
The pop-up preview for a folder on the desktop that’s empty now displays a placeholder message so it’s more obvious what it is, and that it’s not just some weird broken UI element. (Nate Graham, link)
Did you know that KDE is working on our own virtual keyboard that we hope to eventually replace Maliit? Well, we are! The Plasma virtual keyboard got a lot of development attention recently, making it look better and fixing multiple usability issues. (Devin Lin, link 1, link 2, link 3, link 4, link 5)
The Plasma keyboard isn’t quite ready yet, but we’re pushing it forwards to help it reach that point hopefully soon!
Frameworks 6.16
Sorting by date in the open/save dialogs opened by Plasma or any KDE apps now shows the newest files first, rather than last. (Nate Graham, link)
Notable Bug Fixes
Plasma 6.3.6
Fixed an issue that could cause screen flicker when playing full-screen games after switching focus away from them. (Xaver Hugl, link)
Plasma 6.4.2
Fixed a bug that could cause KWin to crash if you removed some of the keyboard shortcuts for the Task Switcher and then invoked it with any of the remaining shortcuts (for example Alt+Tab). (Vlad Zahorodnii, link)
Fixed a regression that prevented the Global Menu widget’s “Single button” mode from working. (Niccolò Venerandi, link)
Reverted a change made to the Powerdevil power management system that prevented it from running for users whose uid values are extremely low or extremely high. (Bhushan Shah, link)
Fixed a regression that caused the screens on certain TVs to go black when turning on HDR mode but not using the TV’s “Game mode” setting. (Xaver Hugl, link)
Fixed a regression that caused some of KWin’s color-related functionality (HDR, ICC profiles, etc.) to not work properly on screens that actually send correct EDID information indicating they are in sRGB mode by default. (Xaver Hugl, link)
Fixed a regression that caused the animated previews for windows on other virtual desktops and shown in the desktop strip of KWin’s Overview effect to be frozen rather than continuing to update live. (David Redondo and Xaver Hugl, link)
Fixed a weird bug that could cause the popup of a standalone Audio Volume widget (not in the System Tray) to change its size after the screen it’s displayed on turns off and back on again. (Christoph Wolk, link)
Fixed a similar weird bug that could, under certain circumstances, cause your Plasma panels to disappear after the screen they’re displayed on turns off and back on again. (Vlad Zahorodnii, link)
Plasma 6.4.3
Fixed an issue that could cause the built-in RDP server to crash when closing invalid connections. (Harald Sitter, link)
Fixed multiple related issues that could cause certain screens to turn on again after being turned off, or vice versa. (Xaver Hugl, link)
Fixed an issue that caused windows created by their app in a very very special way to fail to open. (Vlad Zahorodnii, link)
Fixed two issues with Orca screen reader integration: one that caused “Learn mode” to not work properly, and another caused the use of “Flat review modifier keys” to unexpectedly insert text in any views that allow text insertion which happened to be focused. (Nicolas Fella, link 1 and link 2)
Plasma 6.5.0
Pressing the Esc key while on the Peers Properties dialog for a Wireguard VPN no longer breaks it. (Ivan Tkachenko, link)
Frameworks 6.16
Fixed two cases case where Kirigami-based apps (including Plasma apps like System Settings and Discover) could crash: one when you scroll with a mouse wheel while animations are globally disabled, and another one when software rendering is in use. (Aleix Pol Gonzalez, link 1 and link 2)
Updated the Plasma widget template so that it’s compatible with Plasma 6 and shows modern best practices for widget development. (Tobias Fella, link)
Frameworks 6.16
Improved the system’s ability to detect which GPU is the more powerful one for the purposes of the “Run this program using the more powerful GPU” feature. (Jan Drögehoff, link)
How You Can Help
KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.
You can help KDE by becoming an active community member and getting involved somehow. Each contributor makes a huge difference in KDE — you are not a number or a cog in a machine! You don’t have to be a programmer, either; many other opportunities exist!
You can also help us by making a donation! A monetary contribution of any size will help us cover operational costs, salaries, travel expenses for contributors, and in general just keep KDE bringing Free Software to the world.
After my initial status blog, I was really surprised to see so much support and excitement about Karton, and I’m grateful for it!
A few weeks have gone by since the official coding period for Google Summer of Code began. I wanted to share what I’ve been working on with the project!
VM Installer
Earlier last month, I was finishing up addressing feedback (big thanks again to Harald) on the VM installer-related MR. I had made some improvements to memory management, bug fixes related to detecting ISO disks, as well as refactoring of the class structures. I also ported it over to using QML modules, which is much more commonly used in KDE apps, instead of exposing objects at runtime.
After a bit more review, this has now been merged into the master branch! This was what was featured in the previous demo video and you can find a list of the full changes on the commit.
SPICE Client
Two weeks ago, I started to get back to work on my SPICE viewer branch. This is the main component I had planned for this summer.
It took a few days to clean up my code that connects to the SPICE display and inputs channel.
However, a lot of my time was spent trying to get a properly working frame buffer that grabs the VM display from SPICE (spice-client-glib) and renders it to a native KDE window. The approach I originally took was rendering the pixel array I received to a QImage which could be drawn onto a QQuickItem to be displayed on the window. It listens to SPICE callbacks to know when to update, and was pretty exciting to see it rendering for the first time!
One of the most confusing issues I encountered was when I was encountering weird colour and transparency artifacts in my rendering. I initially thought it was a problem due to the QImage 32-bit RGB format I was labelling the data as, so I ended up going through a bunch of formats on the Qt documentation. The results were very inconsistent and 24-bit formats were somehow looking better, despite SPICE giving me it in 32-bit. Turns out (unrelatedly), there was some race condition with how I was reading the array while SPICE was writing to it, so manually copying the pixels over to a separate array did the trick.
Here are nice pictures from my adventures!
my first time properly seeing the display… (also in the wrong format) ( •͈ ૦ •͈ )
I have also set up forwarding controls which listens to Qt user input (mouse clicks, hover, keyboard presses) and maps coordinates and events to SPICE messages in the inputs channel. Unfortunately, Qt key event scancodes seem to be in evdev format while SPICE expects PC XT. Currently, I have been manually mapping each scancode, but I might see if I can switch to use some library eventually.
Once I polish this up, I hoping to merge this into master soon. It’ll likely be very slow and barebones, but I’m hoping I can make more improvements later on!
still very lagging scrolling, but now we can read Pepper & Carrot!
What’s Next?
While relatively simple, I noticed my approach is quite inefficient, as it has to convert every received frame to a QImage, and suffers from tearing when it has to update quickly (ex: scrolling, videos).
SPICE has a gl-scanout property which is likely much more optimized for rendering frames and I plan on looking into switching over to that in the long-term.
I also need to implement audio forwarding, sending proper mouse drag events, and resizing the viewing window.
On a side note, I also helped review a nice QoL feature from Vishal to list the OS variants in the installation dialog. I’ve just been memorizing them up until now… :')
Hopefully, once I get the SPICE viewer to a reasonable state, I can get back to improving the installation experience further like adding a page to download ISOs from.
As I mentioned a bit previously, I also want to rework the UI eventually. This means spending time to redevelop the components to include a sidebar, which is inspired by UTM and DistroShelf.
Lastly,
I also wanted to make a bit of a note on my plans and hopes throughout the GSoC period. After working on developing these different components of the app, I started to realize how much time goes into polishing, so I believe that I need to prioritse some of the most important features and making them work well.
Overall, it’s been super busy (since I’m also balancing school work), but it has been quite exciting!
Over the past couple of weeks, Timothée Giet has been working on a mock-up tablet and phone friendly UX for Krita. This is a PROTOTYPE, it’s not a working version of Krita. You can’t paint, for instance, or load an image. But you can play with the way the user interface works, and changes depending on orientation and screen size.
The amazing thing, for me, is that unlike our old Krita Sketch, this really looks and feels like Krita, only for mobile touch screens. It’s like this user interface speaks the same language as the desktop interface, krita-ese, I guess you can call it.
Just compare the difference:
Krita Sketch, from 2012The main interface Timothee imagined for Krita.
There’s also a welcome screen:
It works really well and feels really good and logical. Now keep in mind that this is a prototype, and integrating Krita’s canvas with this prototype is going to be quite tough for really complicated technical reasons — and the prototype doesn’t connect to any of Krita’s code at all. So don’t go expecting this to show in the Play Store any time soon!
But I am still really excited!!! Timothée Giet is doing a great job here!
We’re happy to announce the official release of version 1.6.0 of the Qt Extension for Visual Studio Code! After spending some time as pre-release 1.5.0 in the Marketplace, it’s now graduated to a full release. Let's have a look at what's new!
CarlSchwan
