The shell history can quickly become polluted with commands that are
only relevant for specific projects. Running specific unit tests from
project A, starting docker with services needed for project B, etc.
There are some Bash and Zsh scripts that allow you to have separate
histories for each directory you’re in which can be useful in situations
such as these, but the issue is that you get separate histories for each
directory instead of for each project. This means that you would get one
history when you are in project’s root directory, and another when
you’re in some subdirectory of said project.
Instead of creating a separate history for each directory you change
to, it creates separate histories only for directories that are ‘tagged’
with some custom file, be it .git, .envrc or
something else (it is customizable).
For any directory you change to, it will check if that directory or
any of its parents (it will search for the closest parent) contain the
‘tag’ file and it will use that directory as the project root thus
creating a separate history for it.
Installation and
configuration
You just create an array named PER_PROJECT_HISTORY_TAGS
that contains all the file names you want to be used for detecting the
project roots:
declare -a PER_PROJECT_HISTORY_TAGS
PER_PROJECT_HISTORY_TAGS=(.envrc .should_have_per_project_history)
declare -r PER_PROJECT_HISTORY_TAGS
In the example above, any directory that I defined custom environment
variables for using direnv’s .envrc will be treated as
project roots, along with any directory explicitly tagged with
.should_have_per_project_history.
This is useful when you have several source repositories inside of a
single project that should all have a common history, so you can’t use
.git as a tag to detect the project root.
If you don’t define your own tags, the default ones will be used
(.git .hg .jj .stack-work .cabal .cargo .envrc .per_project_history).
Then you just source the per-project-history.zsh file
from the plugin’s
repository.
Or, if you use a plugin manager, add
ivan-cukic/zsh-per-project-history to the list of plugins.
For Zinit, it would look like this:
Dmitry spent time improving framerate of the canvas on Qt6, and implemented support for reading modifier keys while Krita is out of focus on Wayland (MR!2409, MR!2406).
For the July Art Challenge, winner @Katamaheen has chosen "Cool Rides" as the theme. Design a vehicle, optionally add fictional sponsorship logos as suggested by @Mythmaker, and let's race!
Featured Artwork
Best of Krita-Artists - May/June 2025
This month's Best of Krita-Artists Nominations thread received 22 nominations of forum members' artwork. When the poll closed, these five wonderful works made their way onto the Krita-Artists featured artwork banner:
Krita is Free and Open Source Software developed by an international team of sponsored developers and volunteer contributors. That means anyone can help make Krita better!
Support Krita financially by making a one-time or monthly monetary donation. Or donate your time and Get Involved with testing, development, translation, documentation, and more. Last but not least, you can spread the word! Share your Krita artworks, resources, and tips with others, and show the world what Krita can do.
Other Notable Changes
Other notable changes in Krita's development builds from June 6, 2025 - July 16, 2025.
Stable branch (5.2.10):
Animation: Static opacity changes now properly clear animation cache. (bug report) (Change, by Emmet O'Neill)
Animation: Fix incorrect scaling of animated transform mask values. (bug report, CCbug report) (Change, by Emmet O'Neill)
Keyboard Input: Implement option for ignoring of F13-F24 keys on Windows, to avoid problems with certain apps (such as WeeChat) sending unbalanced fake F22 keypresses that confuse the input system. (bug report) (Change, by Dmitry Kazakov)
Unstable branch (5.3.0-prealpha):
File Formats: WebP: Add options to force convert to sRGB embed ICC profile. (wish bug report) (Change, by Rasyuqa A H)
File Formats: JPEG-XL: Improve image mode export options, import multi-page images as layers. (Change, by Rasyuqa A H)
Nightly Builds
Pre-release versions of Krita are built every day for testing new changes.
Cantor is a powerful scientific computing front-end in the KDE ecosystem, providing users with a unified and friendly interface for mathematical and statistical analysis.
Currently, Cantor’s worksheet cells are based on a custom implementation using QTextDocument. While this approach meets basic needs, it has revealed its limitations in terms of feature expansion and long-term maintenance. To fundamentally enhance the editing experience, simplify the codebase, and embrace the advanced technology of the KDE Frameworks, this project plans to deeply integrate the feature-rich KTextEditor component into Cantor, completely replacing the existing cell implementation.
This core upgrade will bring a suite of long-awaited, powerful features to Cantor, including:
Enhanced Multi-line Editing: Significantly improves the editing experience for complex, multi-line code blocks. This includes more robust syntax highlighting, accurate bracket matching, and a more stable editing environment, resolving key issues present in the current implementation.
Vi Mode: Provides native Vi-style text editing for users accustomed to Vim’s efficient workflow, significantly improving editing speed.
Improved Syntax Highlighting: Supports more comprehensive and precise code coloring rules, making complex mathematical and programming expressions clearer and easier to read.
Smart Auto-indent: Enhances code formatting capabilities, making it exceptionally convenient to write structured scripts and multi-line formulas.
Code Completion: Intelligently suggests variables, functions, and keywords, thereby speeding up input and reducing syntax errors.
Spell Check: Ensures the accuracy of text comments and documentation, which is crucial for writing rigorous formula explanations and reports.
By integrating KTextEditor, Cantor will not only optimize the user’s workflow but also reduce code redundancy and improve the project’s overall maintainability. This move will further strengthen the Cantor and KDE ecosystems, providing users with a smoother and more unified experience across different KDE applications.
Why this is needed
As scientific computing demands become increasingly complex, a modern, full-featured editor is essential for boosting productivity. The current custom implementation has become a bottleneck hindering Cantor’s future development:
High Maintenance Cost: Maintaining a custom editor component consumes significant development resources and struggles to keep pace with the advancements in modern editors.
Difficult to Extend: Implementing complex features like Vi mode or advanced code completion on the existing architecture is akin to “reinventing the wheel”—it’s inefficient and prone to introducing new bugs.
Failure to Leverage the Ecosystem: The KDE Frameworks already provide the very mature and powerful KTextEditor component. Not utilizing it is a waste of available resources. Integrating KTextEditor means Cantor can directly benefit from the years of effort and refinement the entire KDE community has invested in this component.
Current Status: Phase 1 Complete
The first phase of the project has been completed. We have successfully introduced Cantor into the core of KTextEditor and achieved the following key results:
Core replacement completed：We created a new WorksheetTextEditorItem class, which acts as a proxy for KTextEditor::View, successfully replacing the old QTextDocument-based cell implementation.
Basic functions available：Users can already perform basic operations such as text input and code execution in the new cells, proving the feasibility of the integration solution.
short text
multi-line display
integration of KTextEditor features：Basic syntax highlighting and text editing features are now available in new cells.
Python
Maxima
Lua
Event Handling and UI Interaction: Core user interactions such as mouse events and drag-and-drop functionality for worksheet entries are working as expected within the new framework.
drag
shotcut key
The Road Ahead: The Plan for Phase 2
With the foundation now firmly in place, the second phase of the project will focus on unlocking the full potential of KTextEditor and refining the user experience. The planned work includes:
Activating Advanced Editor Features: We will progressively enable and configure KTextEditor’s sophisticated features, including Vi Mode, integrated Spell Check, and smart indentation rules, ensuring they are seamlessly integrated into the Cantor workflow.
Connecting Backend-driven Code Completion: A major goal is to connect Cantor’s various computation backends (e.g., Python, R, Octave) to the KTextEditor code completion framework. This will provide users with context-aware, intelligent suggestions.
Bug Fixing and UX Polishing: We will systematically address any remaining issues from the initial integration, focusing on perfecting UI/UX details like focus management, text selection, and context menu consistency.
Comprehensive Testing: Rigorous regression testing will be conducted across all features—new and existing—to guarantee the stability and reliability of Cantor following this major architectural upgrade.
Today we're releasing Krita 5.2.11! This is a bug fix release for Krita 5.2.10, especially for Krita on Android where there were intermittent issues displaying the canvas properly.
Bug Fixes
Fix an issue updating the canvas when entering/exiting canvas-only mode
Fix an issue in the index colors filter when trying to apply the filter to a layer that has only one, non-transparent color
If you're using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the Krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.
[!NOTE]
We are no longer making 32-bit Windows builds.
Note: from 5.2.11, the minimum supported version of Ubuntu is 22.04.
[!WARNING]
5.2.11 has updated the AppImage runtime, which is known to be incompatible with the old versions of AppImageLauncher. Developers of the AppImage runtime suggest to remove or update AppImageLauncher. See this report: Issue 121
More AppImage troubleshooting info is available here: FUSE
We consider Krita on ChromeOS as ready for production. Krita on Android is still beta. Krita is not available for Android phones, only for tablets, because the user interface requires a large screen.
The Linux AppImage and the source .tar.gz and .tar.xz tarballs are signed. You can retrieve the public key here. The signatures are here (filenames ending in .sig).
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
This is a bit of a rant; feel free to skip it if you’re here for the KDE content.
This isn’t the first time I’ve blogged about the dearth of truly great PC laptops out there, and I suspect it won’t be the last.
I limit myself to a single computer for simplicity’s sake, so it has to be a laptop. And since I replaced my 2020 Lenovo ThinkPad X1 Yoga a year ago, I haven’t succeeded at finding a truly great replacement yet. From a certain point of view, you could say I’m a picky buyer, judging by my list of requirements. But frankly, I think these requirements are not that unreasonable. All I want is a laptop that gets the basics right:
Good screen with a DPI suitable for 175-200% scaling, generally between 240 and 280 DPI
Good keyboard with text navigation keys (Home, End, Page Up, and Page Down) and a sensible layout: delete at the top right, no stupid replacement of normal modifier keys with fingerprint readers or copilot keys, no tiny arrow keys, etc.
Good touchpad that’s precise, doesn’t lag, and allows clicking on most or all of the total area
Good speakers that get reasonably loud and don’t have downward-facing tweeters
8 hours of battery life with low usage
Reasonably fast CPU
Reasonable GPU performance for desktop compositing and playing couple-year-old games
Replaceable disk
Just the basics; no great world-shattering innovation needed, and that’s before I narrow the search to laptops that lack NVIDIA GPUs and have touch or 2-in-1 capabilities (which I quite like and are highly useful for testing touch support in KDE software). So it has to have great Linux and Plasma compatibility too!
I’ve closely followed the PC laptop market for 9 years, maintaining a giant spreadsheet of every laptop model and how they fare on the above characteristics plus many more:
The multi-year trend is “one step forward, one step back.” Most companies still change their laptops’ keyboard layouts in random negative ways every year; ship with stupid screen resolutions, woefully bad speakers, and disappointing touchpads; and stuff the most powerful processor and GPU in there and don’t focus enough on tuning the cooling, power usage, and fan profiles.
Some examples from my own usage:
My 2016 HP Spectre x360 was slow and had a poor screen DPI and a laggy touchpad. The 2024 model fixed those problems but lost its HDMI ports and text nav keys, and the USB-A port has a fiddly and annoying little hinge that’s hard to use and will eventually break. And then the 14″ version was canceled in 2025.
My 2020 Lenovo ThinkPad X1 Yoga was also slow, had miserable battery life and a loud fan, put the Fn and PrintScreen keys in inconvenient places, and its high resolution 4K screen option had too high a DPI, wasting energy. The 2025 model fixed those issues but lost the excellent quad speaker system, garaged pen, and the third key to the right of the spacebar that let you re-bind one of them into being a second Meta key.
None of this would be a problem if you could customize and upgrade laptops like you can with desktops, but you can’t. Even on the Framework 13 laptop which makes this an explicit selling point and has made huge leaps in 4 years, there still aren’t aftermarket speaker modules that sound good or a keyboard deck with text nav keys. And the touch/2-in-1 capabilities are only offered on the 12″ model.
Where are the great laptops?
Let’s step back a bit and try to figure out what’s going on here. We have an industry of over a dozen PC manufacturers selling thousands of products, but few truly great ones that are satisfactory in all ways, not just a few.
I feel that a major problem is over-complicated product lines. Let’s look at what the big companies offer.
Seven product lines (or is it eight; there’s an extra one in the sidebar not shown in the main view) and 330 distinct models! How can a normal person who isn’t a laptop enthusiast find anything in here? Even my eyes glaze over when I’m trying to distinguish the differences between the models and product lines.
HP further complicates things by having separate sites for consumer laptops and business laptops. First the consumer laptops:
12 product lines with 67 models. Already a lot. But now add in the business laptops:
7 product lines with 352 models! Absurd. HP implicitly acknowledges the problem by advertising a sales advisor you can chat with to help you make heads or tails of this overwhelming mess (and maybe steer you towards more expensive models):
In total, HP offers 19 product lines and 419 models. Madness, I tell you. Sheer madness.
ASUS makes it even harder by dividing their models into micro-targeted audiences, which makes no sense since there’s overlap in all these use cases and only limited differences between what any of them need in a laptop:
Ultimately I found 8 product lines with 289 models on the US site. Yikes!
MSI does similar segmentation but finds a way to make it even worse by putting more models in each high level category and not offering a “See all” page:
Hmm, do I want a Titan gaming laptop, or a Raider? Maybe a Vector ? Perhaps a Cyborg, or is that a Thin? Apparently they can’t even settle on one name for half of them. Ultimately MSI has divided their laptops into no fewer than 16 product lines with 159 models.
10 product lines, 70 models. A bit better than some of the competition, but 70 total is still an objectively ridiculous level of choice to offer, especially considering that most of these models are going to offer various configurations of CPUs, memory, and storage space.
I could go on, but you get the idea.
You might think that this level of choice should provide anything one could want, but that’s not true. Most of the models differ by like 1% and make all the same mistakes, copy-pasted across the while product line. Maintaining so many product lines at a reasonable level of development and quality is impossible, even for companies of their size with billions of dollars to throw at the problem.
These companies are clearly trying to micro-target specific market segments to match prices to buyers’ budgets, but offering so much choice is foolish. Most buyers — even big commercial buyers — are not informed enough to be able to pick the perfect device from among a massive blob of options presented at the same level, causing choice paralysis and lost sales, disappointing purchases that reduce brand loyalty, and expensive returns.
There has to be a better way!
Who’s doing it right?
There are some bright spots in the industry.
The most notable is Apple, which offers two product lines and five total models. The differences between them are 100% comprehensible. No matter what Apple laptop you choose, it has a world-class touchpad, great speakers, an at-least-good keyboard with a sensible layout, a nice high DPI screen, great performance, and mind-blowing battery life. There are no bad models (if you’re a Mac fan, of course).
Razer is up there too, with one product line and three models, and all of them mostly get the basics right.
Framework also does a great job, also with just three models. The Framework 13 is so close to being the perfect do-it-all general purpose device for me. It just needs text nav keys, better speakers, and a touchscreen (ideally in a 2-in-1 form factor like the 12).
The small Linux-specific StarLabs company does an unexpectedly great job too, with the same three models (hmm, perhaps there’s a pattern here). And these aren’t Clevo or Tongfang units, either! They’re really nice custom engineered Linux-first laptops. I’ve come close to buying one on two occasions within the past year.
And notably, these companies’ laptops tend to get better with each revision, rather than oscillating around a specific level of quality but never consistently improving.
How to not confuse the hell out of people
It’s not that hard: offer a small number of product lines and models with very clear segmentation (by screen size, presence or absence of a GPU, 2-in-1 vs clamshell laptop, etc) and make all of them good. Don’t sell any bad models that have crappy screens, keyboards, touchpads, speakers, or battery life. Don’t sell any models that are 99% identical to other ones. Don’t do this:
No, don’t do this! Stop it! You’re hurting me!
Then make each product better every year. Don’t just put in a new generation of CPUs and ports when they become available; be thoughtful and actually make things better. Reduce power consumption, fan noise, and heat emissions. Tune the speakers to sound better. Increase the screen backlight’s brightness. Put in a nicer, higher-resolution webcam. Increase the number of microphones, and add hardware noise cancellation. Tighten up the ports so they aren’t wobbly. Thicken the case to make it more durable. Beef up the hinges. Use captive screws for the bottom cover. Lighten or roughen the surface a bit to resist fingerprints. Make it easier to remove keys for cleaning without breaking their attachment mechanism. Make the whole keyboard replaceable.
And so on. You know, care about the product! The way we do in KDE for Plasma and our apps. Make it better. Admit and undo your mistakes. Double down on your strengths. And make something great you can be proud of!
A few companies are already there, and I hope someday more follow in their footsteps.
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.
Every week we cover the highlights of what’s happening in the world of KDE Plasma and its associated apps like Discover, System Monitor, and more.
This week features for Plasma 6.5 started to take shape. Day/night appearance changes and digital art are going to be some of the big areas of improvement, so get ready!
Notable New Features
Plasma 6.5.0
You can now configure what rotatable dials on your drawing tablet do! (Joshua Goins, link 1, link 2, and link 3)
When sharing the current Wi-Fi network, its password is now shown as well, so the person you’re sharing it to can easily connect. (Ivan Tkachenko, link)
Notable UI Improvements
Plasma 6.4.3
Improved the accessibility of the Welcome Center app in multiple ways. (Nicolas Fella, link)
KWin’s Magnifier effect now has a maximum magnification level, since going beyond this just turns it into the Zoom effect. (Vlad Zahorodnii, link)
Improved the display of raw bytes in notifications involving file transfers. (Kai Uwe Broulik, link)
Plasma 6.5.0
With the new feature to automatically change wallpapers between their light and dark versions, there’s now more than one feature that makes use of the day/night cycle. Accordingly, the place where you configure your location so the system knows what sunrise and sunset timings to use has been moved out of the Night Light page in System Settings and onto its own page. The cycle you set up here will be used for both Night Light and automatic wallpaper switching, and later for automatic theme or color scheme switching too, once either of those are finalized. (Vlad Zahorodnii, link 1 and link 2)
Screencasts of specific windows now include their titlebars, borders, and shadows. (David Redondo, link)
Notable Bug Fixes
Plasma 6.4.3
Fixed an issue that could cause KWin to crash when you Alt+Tab out of certain games. (Vlad Zahorodnii, link)
Fixed an issue that could cause KWin to crash while using a drawing tablet pen when an internal window closes. (Vlad Zahorodnii, link)
Fixed a regression that caused window focus to be wrong after switching activities. (Vlad Zahorodnii, link)
Fixed a very strange issue that caused apps launched from within Spectacle (for example a video player to view saved screen recordings) to be super duper broken. (Nicolas Fella, link)
Fixed an issue that would prevent Plasma pop-ups from being focusable if a pop-over window from a GTK 4 app was open. (David Edmundson, link)
Using the “Activate and Raise” click setting on Wayland no longer eats clicks while a tooltip is visible. (Vlad Zahorodnii, link)
Fixed an issue that caused window resizing when using a fractional scale factor to be a bit chaotic-looking. (Vlad Zahorodnii, link)
Fixed an issue that caused the Orca screen reader to not work quite right when pressing structural navigation keys repeatedly. (Michael Weghorn, link)
Made the Minimize All Windows widget to work on X11 again. (Marco Martin, link)
The ”Dim Inactive” KWin effect no longer also dims Alt+Tab switchers. (Vlad Zahorodnii, link)
Adapted our code to a Qt change that caused the lock screen to sometimes show the UI and password prompt immediately, rather than only after any interaction. (Marc Payne, link)
Plasma 6.5.0
Fixed an issue that made it impossible to change the background for the SDDM login screen to a new image with the same file name as the old one. (Amy Rose, link)
Fixed an issue that caused authentication prompts to inappropriately reject any already-entered text even if you hadn’t accepted it yet, but rather just because the underlying PAM system was taking a long time. (Secureblue, link)
Frameworks 6.17
Fixed an issue that caused the drag-and-drop menu to sometimes not appear when expected upon dropping files from Dolphin onto the Plasma desktop. (Akseli Lahtinen, link)
Fixed a memory leak in KWin. (Vlad Zahorodnii, link)
Plasma 6.5.0
You can now kioclient mkdir to create a directory going through the KIO system. (Bernardo Gomes Negri, link)
Frameworks 6.17
Slightly improved performance and efficiency for all QtQuick-based KDE apps — including Plasma apps like System Settings, Discover, and Spectacle. (David Edmundson and Marco Martin, link 1 and link 2)
How You Can Help
KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.
You can help KDE by becoming an active community member and getting involved somehow. Each contributor makes a huge difference in KDE — you are not a number or a cog in a machine! You don’t have to be a programmer, either; many other opportunities exist!
You can also help us by making a donation! A monetary contribution of any size will help us cover operational costs, salaries, travel expenses for contributors, and in general just keep KDE bringing Free Software to the world.
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.
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.
@ivan:kde.org
GSoC
.png)
ngraham
