The main goal of this project is to add accessible functionality for users. This wouldn't be possible without buttons to activate those tools! This week’s focus was all about giving the user more direct access to selection tools by placing actionable buttons on top of the floating bar right on the canvas.
QPushButton and connect()
During the halfway point check in with Emmet, I got advice to look into QAction and QPushButton. I learned that QAction held a lot of the Selection Tool actions I was looking for like 'Select All' and 'Deselect' in kis_selection_manager.cc. The QPushButton creates a clickable button. To make the button respond to user input, I connected the button's clicked() signal to the slotted action with Qt's connect() function.
// Example
connect(sender,signal,receiver,slot);connect(buttonObjectWithSignal,buttonSignal,objectWithAction,objectActionToActivate)// Commited Code
connect(d->buttonSelectAll,&QPushButton::clicked,d->selectionManager,&KisSelectionManager::selectAll);
This really helped me set the foundation for triggering selection actions.
I added a couple of QPushButtons that appear on the floating bar. The placement and visibility are currently hardcoded as a proof-of-concept to quickly test the functionality and visual layout.
In order to connect() the button's signal to the selection actions, it was important to learn how to pass in and reference the KisViewManager and KisSelectionManager which contained the selection actions. By creating a function within KisSelectionAssistantsDecoration to set the declared references of KisSelectionManager and calling it after KisSelectionAssistantsDecoration is instantiated, I was able to pass in the selection action function I wanted to activate.
Adding a floating button might seem like a small thing, but it lays the foundation for a more interactive and intuitive user experience in Krita. Seeing it appear directly on the canvas and being able to click it feels like I made real progress!
Right now, the layout and behavior are still pretty basic as the floating bar and buttons' positions are hardcoded, but it proves the concept works. I also learned a lot about how to pass around references like KisViewManager and KisSelectionManager in order to access and trigger the selection actions.
Next week, I plan to continue to find the selection actions I need, add those selection buttons, and improve on the hardcoded positions!
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
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
@rossr:matrix.org
notmart
.
