Thursday, 10 July 2025

Diving into Plasma Bigscreen 🔗

Devin Lin (espidev) 19:00 +00:00
RSS

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.

Background 🔗

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.

Stepping in 🔗

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…

Housekeeping 🔗

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.

Merge requests:

UI 🔗

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.

Homescreen 🔗

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.

Merge requests:

Settings 🔗

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)
  • Wi-Fi KCM (ported to new UI)

Merge requests:

Startup feedback 🔗

The UI feedback for starting an application was broken, so I decided to overhaul it to be something similar to what we have on mobile:

Merge request:

Envmanager 🔗

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.

Merge requests:

Trying it out 🔗

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.

Note: If you are trying to build and install on postmarketOS yourself, be sure install the dependencies and pass the build flags in this manifest, as they are required: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/ee4de8c6702a113914d6ed899c88cb9411e75427/packages/plasma-bigscreen/APKBUILD#L57

As a user you can otherwise install plasma-bigscreen from the nightly repo, or use the AUR package on Arch (though I haven’t tried it).

It’s dangling off the HDMI cable, I know

Applications 🔗

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.

These are some of the ones I tried from Flathub:

  • Kodi - Works well with arrow navigation, allows you to manage a local digital library of content
  • VacuumTube - Provides the YouTube TV web UI wrapped in an application, works well with arrow navigation
  • Jellyfin - I don’t have a Jellyfin server; it launches fine but I don’t think it supports arrow navigation
  • SuperTux - Fun game!
  • SuperTuxKart - It ran somewhat poorly on the Pi, but playing it with a controller was quite nice!

Of course, we also have KDE applications designed for TV:

Controller support 🔗

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.

Other contributors 🔗

Seshan and User8395 have also been contributing to the project here and there in the past few weeks, here are some highlights:

Unresolved issues 🔗

There is still a lot to work on in the project.

Input 🔗

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.

Application design 🔗

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.

Goals 🔗

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.

Getting it released again 🔗

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.

Overall 🔗

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.

Feel free to join us in the Bigscreen Matrix group #plasma-bigscreen:kde.org!

Get Better QML Code Completions with CodeLlama 13B-QML and 7B-QML v3 🔗

Qt Dev Loop 11:40 +00:00
RSS
Get Better QML Code Completions with CodeLlama 13B-QML and 7B-QML v3

Today, we released updated versions of the fine-tuned CodeLlama 13B-QML and 7B -QML models. The updated versions include the first skills to complete code for Qt Quick enhancements in Qt 6.9 and Qt 6.10.

Week 5 recap GSoC 2025 - Toggle the Selection Action Bar 🔗

rossr @rossr:matrix.org 00:00 +00:00
RSS

Intro

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.

Files and Implementation

/krita/libs/ui/dialogs/ kis_dlg_preferences.cc

/krita/libs/ui/forms/ wdggeneralsettings.ui

/krita/libs/ui/ kis_config.h kis_config.cc kis_selection_decoration.h kis_selection_decoration.cc

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

Wednesday, 9 July 2025

KWallet to SecretService, a client application: name wanted 🔗

Marco Martin notmart 15:22 +00:00
RSS

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 😉

The application can be tested at https://invent.kde.org/mart/kwallets

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 😄.

Tuesday, 8 July 2025

Amarok 3.3 "Far Above the Clouds" released! 🔗

The Amarok Development Squad 20:00 +00:00
RSS

The Amarok Development Squad is happy to announce the immediate availability of Amarok 3.3 "Far Above the Clouds"!

Amarok 3.3 screenshot

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.

Packager section

You can find the tarball package on download.kde.org and it has been signed with Tuomas Nurmi's GPG key.

KDE Applications snaps 25.04.3 released, plus new snaps and fixes! 🔗

Scarlett Gately Moore @sgmoore:kde.org 15:25 +00:00
RSS

I have released 25.04.3 I have upgraded the QT6 content snap to 6.9! Fixed a bug in kde-neon* extensions with cmake prefix path.

New snaps!

Audex: A CD ripping application.

GCompris – An excellent childrens education application

Labplot – Scientific plotting

Digikam – 8.7.0 with exiftool bug fixed https://bugs.kde.org/show_bug.cgi?id=501424

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!

July Software Releases: Plasma Camera & Plasma Settings 🔗

Plasma Mobile 00:00 +00:00
RSS

A new version of Plasma Camera and Plasma Settings have been released

These are the independent software releases of July 2025.

Plasma Camera is a newcomer this time around, having been ported to a libcamera backend. Read Andrew's blog or Devin's blog to learn more about it!

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 Gear release cycles.

Source code

The tarballs have been signed by Devin Lin 23919AE71103C02137422E3C5E023F97C5BB4C13.

LocationSizeSha256 Sum
plasma-camera-2.0.097kBe021cd9addfb966f7131923251a1ccc59b6b2ea0c945724c1cc23d8140eb2583
plasma-settings-25.07.097kBdc4e90bb0ed40fd8f032956502b5f2f48ecfe8dad25e885e911d9a5b7ea36167

Week 4 recap GSoC 2025 - draft merge request and feedback 🔗

rossr @rossr:matrix.org 00:00 +00:00
RSS

Intro

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

Monday, 7 July 2025

Kdenlive 25.04.3 released 🔗

Kdenlive 06:40 +00:00
RSS

The last maintenance release of the 25.04 series is out with fixes to the volume and transform effects as well as some issues with guides.

For the full changelog continue reading on kdenlive.org.

A libcamera port of Plasma Camera 🔗

Devin Lin (espidev) 00:00 +00:00
RSS

Cameras!

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!

Background 🔗

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.

Porting Plasma Camera 🔗

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.

The API for libcamera is fairly comprehensive.

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.

UI work 🔗

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
  • Settings persistence

Results 🔗

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.

Limitations 🔗

Video recording issues on phones 🔗

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.

Rotation issues 🔗

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

Missing camera controls 🔗

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!

Conclusion 🔗

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.

So, give it a try! And feel free to come join us to talk about it in the Plasma Mobile matrix channel!