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.
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.
This week, I revisited the KUiServerJobTracker issue in the PIM Migration Agent. After last week’s D-Bus debugging and architectural cleanup, it became clear that replacing it entirely was more complex than initially expected.
After discussing with my mentor Carl, he summarized the situation in an email to the KDE PIM mailing list. In it, he outlined the limitations we were facing:
“The agent relies on KUiServerJobTracker, which aside from requiring a port to KUiServerV2JobTracker, also has the issue that it links to QtWidgets while not using QWidget itself.”
The email resulted in feedback from Volker Krause. In his response he agreed with one of Carl’s suggestion that I ultimately pursued: rather than remove the job tracker altogether or build an entirely new progress infrastructure, I created a local copy of KUiServerV2JobTracker inside the kdepim-runtime repository and carefully stripped out its QtWidgets linkage.
This forked version is temporary and self-contained, with a clear path to removal once the upstream KDE Frameworks address the QtWidgets dependency—likely by KF7. It allowed me to retain proper system tray integration for job tracking (which AgentBase’s built-in D-Bus support cannot currently provide), while still meeting the goal of removing QtWidgets from the Migration Agent’s core.
Shedding the Final Dependencies
With the tracker replaced, I focused on removing the last traces of QtWidgets from the Migration Agent. This included cleaning up the custom D-Bus interface and eliminating now-redundant methods. The final dependencies were located in individual subcomponent CMakeLists.txt files, which were still linking against QtWidgets.
After updating those, the result is a fully decoupled agent:
The PIM Migration Agent’s core logic is now completely free of QtWidgets.
In addition, I integrated the manual migration tasks into the job executor, allowing them to report progress using the same job tracking mechanisms as the automated tasks.
A New Akonadi Capability: SingleShot Agents
The mailing list discussion also highlighted another inefficiency: the Migration Agent doesn’t need to run persistently. As Volker suggested:
“Keep it as an agent but give it a special ‘SingleShot’ flag… with Akonadi shutting it down again automatically once done.”
Building on this idea, I introduced a new Akonadi capability: SingleShot agents. This lets agents perform their work once and automatically exit afterward, conserving system resources.
The mechanism works as follows:
An agent declares X-Akonadi-Capabilities=SingleShot in its .desktop file.
When launched, the agent does its work.
Once finished, it emits a new finished() D-Bus signal.
The Akonadi manager listens for this signal and terminates the agent process.
This pattern fits well with agents like the Migration Agent that don’t need to remain active beyond their immediate tasks.
Current Status and What’s Next
Draft merge requests for both akonadi and kdepim-runtime are already open to gather feedback on the SingleShot capability and the updated job tracking approach.
The only remaining issue is that the finished() signal doesn’t seem to shut down the agent as expected when testing through akonadiconsole. Debugging this signal propagation is my focus for the upcoming week. Once resolved, the agent will fully behave as a lightweight, on-demand component.
This week’s changes not only complete the agent’s QtWidgets decoupling but also introduce a meaningful architectural improvement to Akonadi itself—one that may benefit other agents in the future.
notmart
.
@sgmoore:kde.org
