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
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.
@ivan:kde.org
GSoC
.png)
notmart
.
