With the Migration Agent and SingleShot capability now submitted for review, this week marked the halfway point of Google Summer of Code and a natural moment to shift focus to a new component: the NewMailNotifier Agent.
The goal remains the same—decoupling Akonadi agents from QtWidgets to make them lighter, modular, and easier to integrate across different platforms.
Reviewing the Architecture
The NewMailNotifier Agent is responsible for generating notifications when new email arrives. Upon inspection, it became clear that significant progress had already been made in decoupling this agent: its configuration UI was already implemented as a standalone plugin. For the most part, the agent could run headlessly.
However, one lingering QtWidgets dependency remained, preventing full decoupling. The focus this week was to identify and plan its removal.
Identifying the Remaining Dependency
With guidance from my mentor Carl, I located the source of the issue: a method named showNotNotificationHistoryDialog().
This method is exposed over D-Bus and instructs the agent to display a Qt-based dialog listing recent notification texts. While functionally useful, this forces the core agent process to link against QtWidgets—just to open a dialog. This runs counter to the goal of creating lightweight, headless agents.
Refactoring Toward Separation of Concerns
To address this, Carl proposed a more modular design that better separates responsibilities between the agent and user interface components. This week was dedicated to exploring and implementing that approach:
Revising the D-Bus Interface: Instead of a method that opens a dialog, the agent will expose the notification history as a read-only D-Bus property. This allows client applications to retrieve the data without triggering any UI logic.
Relocating UI Logic to KMail: The dialog used to display the notification history will be moved from the agent (in kdepim-runtime) to KMail, the primary user-facing application.
Delegating Presentation Responsibility: Going forward, KMail (or any other compatible client) will read the history data via D-Bus and handle its own UI, enabling greater flexibility and maintaining a clean separation between data handling and presentation.
Current Status and What’s Next
The changes have already been started, and the updated D-Bus interface is mostly in place. Some parts of the dialog code have been moved to KMail, but the full integration still needs testing and a few finishing touches.
Next week, I’ll focus on verifying that everything works correctly, polishing the implementation, and preparing the merge request for review.
Once complete, this will remove the last QtWidgets dependency from the NewMailNotifier Agent and continue the ongoing effort to modularize KDE PIM components.
I have been a long time Plasma Mobile contributor, but I have always had a keen interest in having Linux on my TV! I have noticed that in the past few months, the Plasma Bigscreen project has had some interest from people wanting to contribute, but there have not been any active KDE developers working on the project. Since I have some time off school (having just graduated university), I decided to take a swing at improving the project for a week.
Plasma Bigscreen is a Plasma-based shell (desktop environment) for TVs and other large displays. It is designed to be used with arrow navigation using remotes or controllers.
I have not been involved with the project in the past so its history is a bit murky to me. From what I know, it was originally developed with Mycroft in mind, which was a open source virtual assistant. They had even developed hardware for it, but unfortunately, the company shut down in recent years. The work by the developers at that time appears to have been sponsored by Blue Systems.
Plasma Bigscreen itself emerged around 2020 and was designed as a “Plasma shell”, in a similar way to Plasma Desktop and Plasma Mobile. Back when development was active, it provided a TV friendly launcher to launch Linux apps, and even had its own “mini-apps”, known as Mycroft Skills. These could be downloaded from the KDE Store. A TV-friendly web browser and media player were also developed for the project. The project itself was released in the Plasma 5 release cycle, but got dropped with Plasma 6 in 2024 because it was not ported in time for the megarelease.
About a year ago, the project was ported to Plasma 6 (and Qt 6), but has not yet received a release since being removed from the Plasma release schedule.
A few months ago, my friend Seshan started doing some work and opened a few merge requests against the Plasma Bigscreen shell repository. I noticed that there had basically been no activity on the repository since the initial Qt6/Plasma6 port, and the matrix channel had no active developers. I sensed an opportunity…
I started with some housekeeping work with the repository. I added a README, and a REUSE license checker to the CI. I then ported the QML library to be a declarative plugin, and removed a bunch of abandoned code folders that were not used anywhere in the codebase.
At this point prior to my work, the shell UI looked like this:
I was digging around some old Breeze Ocean mockups and stumbled across some Bigscreen mockups by Manuel. It seems the original Bigscreen UI did try to follow it, but did not quite get there. I felt inspired to fully complete implementing them.
I first worked on the homescreen UI. I flattened the layout to reduce visual complexity, removing panel backgrounds and shadows where possible, while adding tooltips for the indicators. I then added an “expanded clock” view for when the user is at the top of application categories (based on the mockups), which shrinks when the user goes down the view. I ported the application lists to use ListView and delegate caching rather than having all elements having their coordinates positioned manually to improve performance. The background now also blurs when it is not the main focus of the UI.
I also added a search view based on KRunner. This allows users to search for the applications they need without needing to manually scroll through the entire application list.
I redesigned the system settings view to have a sidebar with categories, with a simple two-pane look.
The settings modules (KCMs) had a lot of hardcoded UI elements and layouts. I decided to make a small component library to build TV focused UIs (that still look Breeze like), and ported all of the settings modules to it. I moved away from horizontal layouts to vertical layouts for content, and put a heavier emphasis on sidebars for interacting with individual delegates. I think it looks pretty nice:
I ported settings modules to my controls library, and also fixed some issues:
Display KCM (rewritten with libkscreen backend, as it was otherwise completely broken)
Sound KCM (ported to new UI)
KDE Connect KCM (ported to new UI, fixed some state issues)
Bigscreen KCM (ported to new UI, fix shortcuts, fixed timezone selection)
I wrote envmanager as a program in Plasma Mobile that manages shell specific configuration we need in services such as KWin. This avoids the need for distros to ship custom configs to set certain settings that the shell needs. I recently changed Plasma Mobile to use config overlays in order to achieve this, with more details can be found in my other blog post.
In order to try it out (on a TV for realsies, not just on my workstation), I used a Raspberry Pi 5. I flashed postmarketOS onto it, and then manually compiled and installed the Plasma Bigscreen shell.
In its heyday, Plasma Bigscreen relied on “Mycroft Skills” to provide some media applications such as YouTube and SoundCloud. We do not have that anymore, so I tried out some other Linux applications.
There is a repository called plasma-remotecontrollers, which contains a daemon that is able to take both game controllers (ex. Xbox) and TV remotes (over CEC on HDMI) and map them to keyboard arrow keys. It also has a settings module to configure the shortcuts.
I was able to successfully test having an Xbox controller connected (with the daemon online), and having it map the arrow buttons to arrow keys on the system. I wasn’t able to however test the CEC support, which would allow buttons on TV remotes (over HDMI) map to arrow keys.
There isn’t a virtual keyboard to input text with that supports arrow navigation. This is something planned for Plasma Keyboard however, please stay tuned!
The plasma-remotecontrollers’s (TV remote/game controller support) settings module is also not yet properly ported and tested on Bigscreen.
So… it is probably best to still use a bluetooth keyboard and mouse for now, or an air remote.
We do not have any framework to design TV-based UIs in KDE. Aura browser and Plank both use Qt Quick Controls and Kirigami, but have a lot of hardcoding and custom controls in order to be usable on a TV. I do have a few TV focused components for building settings modules, but that is a very narrow set of controls.
What are the usecases we want to achieve with a TV focused desktop environment? Do we need to also pursue making frontends for various media services? There isn’t a clear direction for the project at the moment, beyond making it a working desktop environment. In the past, this project was heavily focused on Mycroft but that no longer exists.
Distributions dropped their respective plasma-bigscreen packages when Plasma 6 rolled out, as it is no longer part of the Plasma release. We need to have the project return to the Plasma release cycle, hopefully starting with Plasma 6.5.
I am fairly happy with the work that I was able to produce for Bigscreen last month. I have since returned to working on Plasma Mobile (due to having limited time as a volunteer contributor), but I can still step in and help review merge requests and guide new contributors to the project.
Tools are meant to be used as needed. The Selection Action Bar is no exception. So this week I added in a toggle so that users are able to show or hide the Selection Action Bar.
I initially wanted to find a place in settings where a tool, like Selection Action Bar, could be toggled on and off. In the process of researching I added in a checkbox in Settings->Configure Krita->General->Tools. Next, I needed to find when and where a selection tool is active. In kis_selection_decoration, I found that I can render the Selection Action Bar when the selection tool is active and the newly made checkbox in settings is checked. Under kis_dlg_preferences, wdggeneralsettings and kis_config files, the toggle settings checkbox is set and referenced to update the UI.
Conclusion
Users gain control of showing or hiding Selection Action Bar with implementation of a toggle in settings. Although I iniitally planned to build out the buttons after the floating bar, I learned how to conditionally render elements based on user preferences and gain a new perspective on how to approach the feature. I am looking forward to building out the buttons to activate the selection actions next!
Contact
To anyone reading this, please feel free to reach out to me. I’m always open to suggestions and thoughts on how to improve as a developer and as a person.
Email: ross.erosales@gmail.com
Matrix: @rossr:matrix.org
As i wrote in the previous post, now the KWallet service has been splitted in a compatibility layer that exposes the old KWallet api, but actually consumes the Secret Service API, provided by default by the old KWallet daemon converted in a secretservice-only provider.
Another pain point is the application used to look inside the wallets, KWalletmanager, which only speaks the KWallet api and looks a bit dated nowdays:
I am working on a new application which goal is strictly to be a client for Secret Service. It can access passwords of any Secret Service provider (being KWallet, Gnome-keyring, KeepassXC, oo7 or whatever else) and should hopefully look a bit more modern and simple, while still being powerful:
Both as a desktop application or a mobile one:
For items imported from KWallet supports editing the values of type “Map” as well:
As well as visualizing “binary” entries (here super censored for obvious reasons
But has a fundamental problem, for which i need help… Right now is just called “KWallets” which can be kinda confusing with old KWallet and KWalletManager, so it probably needs a new name, any opinion is welcome .
Amarok 3.3.0 is the first version based on Qt6/KF6, corresponding to a decade-sized update of the technological foundations.
Additionally, audio engine has been reworked to use GStreamer for playback. Previously, the availability of various features, e.g. ReplayGain and visualiser,
was dependent on the Phonon backend in use, an issue that became even more evident with Qt6 Phonon backends.
This has now been remedied: The reworked audio engine provides unified feature set for all users and should provide a solid and future-proof sonic experience for years to come.
Notable improvements have also landed to the database system: improved character set support helps with e.g. emojis in podcast descriptions and other very exotic symbols,
date handling has been improved ('year 2038 problem'), and various other potential and actual database-related issues have been fixed.
Amarok 3.3 arrives approximately 15 months after the initial Qt5/KF5 version 3.0 and 5 months after the final Qt5/KF5 version 3.2.2.
Although there have been a number of major changes, they are mostly technical, and their effect on the user experience is relatively minor.
Therefore, the version released now is 3.3.0, with some 3.3.x bugfix releases to be expected in near future.
A new major version ('Amarok 4') will be released later, after more extensive work on the user interface and other aspects of the software has been carried out.
Changes since 3.2.2
FEATURES:
Audio engine has been reworked to use GStreamer instead of Phonon
CHANGES:
Qt5/KF5 support has been dropped
Update database character set to allow full utf-8 values (BR 462268)
Apply default pre-gain when ReplayGain is active and use fallback value if no ReplayGain data is available for a track
Clear out some of the now-discontinued Last.fm radio functionalities and partially replace by opening relevant Last.fm pages
Remove TagLib extras support (RealMedia and Audible files)
BUGFIXES:
Handle volume better and avoid resets on track changes (BR 506427)
Fix year 2038 problem for various dates saved in database (BR 426807)
Default to not allow compiling without embedded database (BR 502777)
Prevent concurrent scan result processings from taking place to avoid potential database issues
Partially re-enable cue file support
The git repository statistics between 3.2.0 and 3.3.0 are as follows: Tuomas Nurmi: 113 commits, +3681, -3101 l10n daemon script: 92 commits, +85094, -89109 Kunda Ki: 1 commit, +4, -11 Carl Schwan: 1 commit, +1, -1
Getting Amarok
In addition to source code, Amarok is available for installation from many distributions' package
repositories, which are likely to get updated to 3.3.0 soon, as well as
the flatpak available on flathub.
Krita – 5.2.11 – Excellent Graphic art platform ( compares to Photoshop )
kgraphviewer – Graphiz .dot file viewer
I am happy to report my arm is mostly functional! Unfortunately, maintaining all these snaps is an enormous amount of work, with time I don’t have! Please consider a donation for the time I should be spending job hunting / getting a website business off the ground. Thank you for your consideration!
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.
Merge requests (MR) are a useful feature in version control systems to propose changes to large codebases. This helps keep track of major changes and organize individual contributions. This week I created a draft MR to keep track of my progress and to gain constructive feedback.
Draft MR
Why use draft MRs instead of just a separate development branch? I'm glad you asked! Compared to a development branch, a draft MR includes commits from your development branch, reviewers can create threads (such as TODO tasks or add comments), and major changes can be tracked so a reviewer has more context behind your changes. On a project with hundreds or thousands of contributors, development branches can be difficult to manage.
Progress
In my draft MR I received valuable feedback and made improvements. So far, I added licensing information, removed placeholder comments (following best practices), and implemented the rendering of the floating bar on Selection Tool activation. I wouldn’t have been able to make these important changes or get one step closer to building out the feature without the feedback. On top of this, by getting feedback through a draft MR, I am able to look back at old threads or comments easily compared to reading IRC or chat through Matrix, which can have multiple active conversations at once.
Conclusion
Getting feedback can be tough if you cannot convey your question properly, cannot provide an example, or you cannot find the appropriate time to ask. Through a draft MR, I was able to get constructive feedback that led to small improvements I could make immediately, instead of creating an MR later down the road and making large changes. This also provides me an opportunity to check in with the community outside of IRC.
I learned that certain modes of communication can be more beneficial than others given the circumstances and keeping track of progress in a transparent manner helps you grow as a developer.
Contact
To anyone reading this, please feel free to reach out to me. I’m always open to suggestions and thoughts on how to improve as a developer and as a person. Email: ross.erosales@gmail.com Matrix: @rossr:matrix.org
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.
@pabarino:matrix.org
notmart
.
