Over the past couple of weeks, Timothée Giet has been working on a mock-up tablet and phone friendly UX for Krita. This is a PROTOTYPE, it’s not a working version of Krita. You can’t paint, for instance, or load an image. But you can play with the way the user interface works, and changes depending on orientation and screen size.
The amazing thing, for me, is that unlike our old Krita Sketch, this really looks and feels like Krita, only for mobile touch screens. It’s like this user interface speaks the same language as the desktop interface, krita-ese, I guess you can call it.
Just compare the difference:
Krita Sketch, from 2012The main interface Timothee imagined for Krita.
There’s also a welcome screen:
It works really well and feels really good and logical. Now keep in mind that this is a prototype, and integrating Krita’s canvas with this prototype is going to be quite tough for really complicated technical reasons — and the prototype doesn’t connect to any of Krita’s code at all. So don’t go expecting this to show in the Play Store any time soon!
But I am still really excited!!! Timothée Giet is doing a great job here!
We’re happy to announce the official release of version 1.6.0 of the Qt Extension for Visual Studio Code! After spending some time as pre-release 1.5.0 in the Marketplace, it’s now graduated to a full release. Let's have a look at what's new!
Hi, I'm thrilled to be part of Google Summer of Code 2025 with KDE Community, working under the mentorship of Carl Schwan, Claudio Cambra, and Aakarsh MJ. My project, "Modernize Account Management with QML," aims to enhance the account management system in Merkuro, by transitioning its resource configuration dialogs to QML. This blog post introduces my project and shares the progress I've made in the recent weeks.
About the Project -
Merkuro currently relies on QWidget-based dialogs for managing account resources, which, while functional, are not optimized for modern platform usability, especially on touch devices or diverse platforms. My project addresses this by porting resource configuration dialogs to QML, a modern, flexible, and responsive UI framework, while maintaining compatibility with existing QWidget-based systems. The goal is to create a shared infrastructure that supports both QWidget and QML-based configurations, enabling a seamless transition to modern UI development without disrupting existing functionality.
The project has two main components:
Building a Shared Infrastructure: Creating a foundation that supports both QWidget and QML-based configuration dialogs for Akonadi agents, ensuring backward compatibility and scalability.
Porting SingleFileResource-Based Configurations: Migrating singlefileresource based configurations, such as the ical, vcard, etc to QML to provide a modern, responsive user experience.
Benefits to KDE Community -
Porting Merkuro's account management to QML offers significant benefits:
For Users: QML-based dialogs provide a smoother, more intuitive, and visually engaging experience. QML's flexibility supports dynamic and touch-friendly interfaces, making account management more accessible on various devices, from desktops to mobile platforms.
For Developers: The shared infrastructure improves modularity and maintainability, allowing developers to adopt QML at their own pace without breaking legacy systems. This sets the stage for future QML-based UI development in Akonadi and beyond.
Progress So Far -
1. Implemented Shared Infrastructure for Akonadi
To support both QWidget and QML-based configurations in Akonadi, I developed a new infrastructure in following way:
AbstractAgentConfiguration: A new base class defining standard methods (load(), save(), etc.) for consistent configuration handling.
AgentConfigurationBase: Updated to inherit from AbstractAgentConfiguration, ensuring compatibility with existing QWidget-based dialogs.
QuickAgentConfigurationBase: A new class inherited from AbstractAgentConfiguration, enabling QML-based configurations via shared QML engine for dynamic UIs.
QuickAgentConfigurationFactoryBase: A factory for QML-based configuration instances, complementing the QWidget factory.
This infrastructure, inspired by KCMUtils, enables Akonadi to handle both legacy and modern UI paradigms seamlessly.
2. Ported Knut Configuration Dialog to QML
I removed QWidget based code and then implemented Knut configuration dialog in QML.
And currently working on porting singlefileresource based dialogs....
Challenges Faced -
The progress came with several challenges that shaped my learning:
Testing the QML Infrastructure: Validating the new QML infrastructure during development was difficult, as it required a functional QML-based dialog to test fully. I could only verify the infrastructure’s correctness after porting the Knut configuration to QML, which delayed feedback and required iterative adjustments.
Navigating KDE’s Modular Ecosystem: KDE's ecosystem is vast and modular so understanding each of them is very important. Recently, I spent around hour looking for the Knut configuration dialog in Merkuro only to find out (thanks to Carl) that it actually lives in KOrganizer’s test suite! I was actually unaware of this.
And of course, compiling errors and warnings were always there to keep me company :)
Thank you and stay tuned for the next part, where I’ll share more updates and learnings from my GSoC journey!
Tuesday, 1 July 2025. Today KDE releases a bugfix update to KDE Plasma 6, versioned 6.4.2.
Plasma 6.4 was released in June 2025 with many feature refinements and new modules to complete the desktop experience.
This release adds a week’s worth of new translations and fixes from KDE’s contributors. The bugfixes are typically small but important and include:
Due to systemd limitation causing regression on AD managed systems, fix for CAP_WAKE_ALARM provided in Plasma 6.4.0 release was partially reverted in powerdevil. If your distribution wants to provide support for alarm wakeups from suspend on Plasma Mobile device, Please manually override plasma-powerdevil.service systemd user unit to pass CAP_WAKE_ALARM in AmbientCapabilities.
I switched to static website generation with Jekyll in 2019 (probably because of Carl Schwan, who is somehow my
guiding-spirit in webulous things even if he does Hugo things nowadays). That means Ruby,
and I’ve got various bits-and-notes documents saying things like “When Ruby breaks again, …”
This blog post is my attempt to document for myself, once-and-for-all, my setup.
Basically, this comes down to (gently) fighting the FreeBSD packaging system.
Ruby 3.3 Incompatible
With Jekyll 4.3.1, trying to run it with Ruby 3.3 leads to the following error message:
jekyll 4.3.1 | Error: undefined method `[]' for nil
/usr/local/lib/ruby/3.3/logger.rb:384:in `level': undefined method `[]' for nil (NoMethodError)
@level_override[Fiber.current] || @level
^^^^^^^^^^^^^^^
from ~/.gem/ruby/3.3/gems/jekyll-4.3.1/lib/jekyll/log_adapter.rb:45:in `adjust_verbosity'
This is documented in the release notes for Jekyll 4.3.3.
Upgrade Blockers
So let’s stick with Ruby 3.2 for a bit. On FreeBSD, that means setting a default version for Ruby in /etc/make.conf, like so:
DEFAULT_VERSIONS+=ruby=3.2
Then installing Ruby 3.2, e.g. with pkg install ruby32. Even though the language is still there, other tools like bundler are not, so I had to build sysutils/rubygem-bundler from ports. Once that’s done, managing my Ruby 3.2 environment is workable again.
This is part of the “gently fighting”: getting the versions of the tools to match the version of the language I want. I can’t really blame the central package-repository for not supporting every use-case.
Upgrading Jekyll seems like the right thing to do, and bundle update is the tool to use.
It fails with a peculiar message that suggests that some non-FreeBSD executable is being used:
Installing sass-embedded 1.89.2 with native extensions
ELF binary type "0" not known.
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
Looking into ~/.gem/ruby/3.2/gems/sass-embedded-1.89.2/ there is an ext/sass directory, which contains an ELF executable called true and a file with ^A in its name (control-A, ASCII 0x01). I have no idea what is going on, but it feels like malware delivery while it is probably some developer delivering Linux tools – the readme mentions a Dart-language tool. I don’t feel like installing the Linuxolator to build this one gem today.
Careful With That Axe
This works remarkably well, once Ruby 3.2 and corresponding bundler are installed:
rm -rf ~/.gem
# Edit gemfile to make BUNDLED WITH match current bundler version
bundle install
I have no use for, or patience with, Ruby other than generate-my-damn-website.
This will tide me though until such a time as I update to a slightly-more-modern
static site generator, or freeze the whole thing into a virtual-machine image
that will never change again because .. it’s a static site generator.
I could replace it with vi and some patience.
You may have read about my new-found fondness for Plasma’s Clock app. Following the development of a “Picture in Picture” protocol for Wayland, I remembered how I once saw someone put up a little timer window during a lunch break while screen-sharing a presentation. I figured, I wanted that, too!
KClock showing a timer popped out in a PIP window
A key difference between X11 and Wayland is that Wayland is descriptive, not prescriptive. For example, a drop down menu under X11 is a window with no border that is placed in a very specific location determined by the application. It then grabs all the input so that up and down arrows work and clicking outside will dismiss it. That also means that global shortcuts won’t work while the menu is open. You can’t take a screenshot of it, you can’t even lock your screen. In 2025, this is embarrassing.
Under Wayland on the other hand, such a menu is an XDG Popup. The application tells the compositor what button it came from and what to do when it can’t fit (flip to the other side, scroll, etc). The compositor then gets to decide where to put the menu (not crossing display boundaries, for example) and to make sure it goes away when you click elsewhere or switch to a different application.
This also means that an application is a lot more restricted when it comes to – let’s say – creative window behavior. Take the picture-in-picture feature for example: an application can’t just decide to keep its window on top of everyone else. Normally, that’s a good thing! But it likewise prevents implementing a little overlay video player in your Web browser under Wayland. Enter xx-pip-v1.
Measure lap time while watching a fantastic talk
It’s a protocol very similar to XDG Shell but instead of managing desktop-y windows and popups, it creates floating picture-in-picture windows. KWin recently gained support for it. As indicated by the “xx” prefix it’s an experimental protocol and therefore guarded by a KWIN_WAYLAND_SUPPORT_XX_PIP_V1 environment variable. As with most protocols, having a test case is nice but a proper application making use of it will uncover gaps and oversights in the protocol much better. Therefore, I took the opportunity to allow KClock to pop out timers and the stopwatch into a little PIP window.
While it can and does take time to sketch a Wayland protocol to realze a new use case, the end result will be generally better than anything we had before. Rather than an application deciding how PIP should behave, the compositor is in full control and subsequently you, the user. We could offer an option for which corner the window should be placed by default, or to not show it at all, and do it consistently for all applications.
Many thanks to Vlad Zahorodnii for his work on the xx-pip-v1 protocol and whose demo application the KClock implementation is based on and to David Edmundson for implementing window move/resize in the PIP window.
After four months of active maintenance and many weeks triaging bugs, the digiKam team is proud to present version 8.7.0 of its open source digital photo manager.
Improvements in Photos, KRetro and better keyboard navigation
Welcome to a new issue of "This Week in KDE Apps"! Every week (or so) we cover as much as possible of what's happening in the world of KDE apps.
As you might have noticed, the frequency of "This Week in KDE Apps" has not been very consistent lately. Particularly during the summer season, I (Carl) have a lot of social obligations and can't ensure regular updates with the small amount of time I have available. If you are a KDE developer, you can help by contributing your updates to the GitLab merge request on invent. In that respect, a huge thanks to Felix Ernst for doing that already for Dolphin.
Getting back to all that's new in the KDE App scene, let's dig in!
Akseli Lahtinen increased the click area of files and folders in the main view and overhauled their styling. It's (subjectively speaking) a lot prettier now! We are trying to make Dolphin more consistent with other list styles in KDE long-term (25.08.0 - link).
Méven Car added a colorful folder icon chooser to the context menu of folders (25.08.0 - link). The Dolphin context menu can be edited in Dolphin's settings window.
Aleksandr Borodetckii lowered the default scroll speed to follow the globally-configured scroll distance more closely. Scrolling one "tick" with the mouse wheel should now move the view by a similar distance in Dolphin as it does in KWrite. In details view mode we made sure that scrolling moves by full item height (25.08.0 - link).
Gleb Kasachou added a setting to optionally elide long file names at the end instead of in the middle, so when the Dolphin window is too narrow to display “a very long file name.txt”, you can now switch between showing “a very…file name.txt” or “a very long file….txt”. Both of these behaviors have been respectfully criticized in the past, so now everyone can set it to their liking (25.08.0 - link).
Bojidar Marinov fixed a visual bug in the default icons view mode in a livestream, as sometimes the file name would have one row of text outside and below the actual file geometry (25.08.0 - link).
Akseli Lahtinen fixed a long-standing issue that could cause Dolphin to crash while interacting with Samba shares (Frameworks 6.16 - link).
Kai Uwe Broulik fixed another long-standing issue where a random "Examining" popup would appear when connecting to a busy Samba share (25.04.3 - link).
Sune Vuorela made the list of certificates used to sign a PDF update when switching the active backend (GnuPG or NSS) (25.08.0 - link). If Kleopatra is installed and the GPG backend is selected, Okular will now propose to view the certificate details in Kleopatra (25.08.0 - link).
Abdus Sami made the number of items in the recent history configurable (25.08.0 - link).
Pablo Ariño ported the Etesync resource away from directly depending on QtWidgets. This decreases the RAM consumption by around 10MiB for each running Etesync instance (25.08.0 - link). Carl then ported the resource away from KWallet to the more multiplatform alternative QtKeychain (25.08.0 - link).
Merkuro Manage your tasks, events and contacts with speed and ease
Oliver Beard fixed various bugs in Photos. Sharing now works again (25.08.0 - link) and the bookmark functionality is now consistently called "bookmark" in the UI (25.08.0 - link). He also ported the thumbnailbar to a standard toolbar (link).
Carl Schwan made it possible to configure some shortcuts in Photos and added a command bar (25.08.0 - link). Additionally, he made it possible to configure which metadata details are available in the sidebar (25.08.0 - link).
Carl also optimized the main view a bit (25.08.0 - link 1, link 2 and link 3), unified the breakpoint at which desktop and mobile mode are switched (25.08.0 - link), fixed the video player which was not completely ported away from Qt5 (25.08.0 - link), and made a large number of small cleanups and code modernizations (link).
Jean-Baptiste Mardelle added an action to extend and collapse items in the effects and folders view. This allows navigating these views with the keyboard (25.08.0 - link).
Carl Schwan added support for Deutsches Jugendherbergswerk (DJH) email confirmations (25.04.03 - link).
Stephan Olbrich added support for Deutscher Alpenverein (DAV) membership cards (25.04.03 - link).
David Pilarčík added support for extracting multiple tickets from one PDF for Leo Express (25.04.03 - link) and improved the extraction of the luma extractor (25.04.03 - link).
Joshua Goins overhauled the server information page (25.08.0 - link). You can now view your server's extended description, terms of service and privacy policy (when applicable).
Efe Çiftci added a "Show Folders" action to Filelight that allows toggling the visibility of the folder list on the left-hand side of the window (25.08.0 - link).
For a complete overview of what's going on, visit KDE's Planet, where you can find all KDE news unfiltered directly from our contributors.
Get Involved
The KDE organization has become important in the world, and your time and
contributions have helped us get there. As we grow, we're going to need
your support for KDE to become sustainable.
You can help KDE by becoming an active community member and getting involved.
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. There are many things
you can do: you can help hunt and confirm bugs, even maybe solve them;
contribute designs for wallpapers, web pages, icons and app interfaces;
translate messages and menu items into your own language; promote KDE in your
local community; and a ton more things.
You can also help us by donating. Any monetary
contribution, however small, will help us cover operational costs, salaries,
travel expenses for contributors and in general just keep KDE bringing Free
Software to the world.
To get your application mentioned here, please ping us in invent or in Matrix.
When we were at TU Graz for the KDE Plasma Sprint and Grazer Linuxtage
a few weeks ago the question came up how to practically map such buildings in OpenStreetMap
given their available floor plans. As I’m mostly involved in using rather than creating OSM data I didn’t have
a good answer for that back then. Thanks to input during the following quarterly
OSM Indoor Meetup, you’ll find
some hints on approaches and tools below.
Indoor Mapping
Navigating in complex public buildings is a similar challenge than navigating outdoors, detailed map data is crucial
in both cases. And while indoor mapping is a somewhat niche topic in OSM still, there’s applications such as
Itinerary and Transitous making use of that for
train stations or airports, and Kongress
applying this in conference venues.
For displaying maps split up by floor level we already get somewhat usable results with partial information as
humans are very good in filling in the blanks.
Routing algorithms
however are very dumb and very clever at the same time,
dumb when it comes to making “common sense” assumptions when facing missing information and clever when it comes to finding
creative shortcuts by exploiting incomplete information. So completeness is important here.
Routing algorithm exploiting doors not intended for visitors (left).
And that’s even more the case when looking at accessibility usecases, no matter whether applying human or machine routing.
Every single step somewhere can be a blocker for a wheelchair, and if you rely on tactile guides a mismatch between map
and reality hurts a lot more than when you can fill the gaps by what you see on the spot.
Building plans
The hard part of mapping building interiors is usually to get the geometry of rooms, corridors, walls, etc. in correctly.
Measuring this all by hand in reference to the outer structure is a very tedious job, tools commonly used for outdoor
mapping such as GPS and geo-referenced aerial imagery wont help here.
Images of to scale floor or evacuation plans are usually easier to obtain. Those generally cannot be imported
automatically, but offer a similar help as aerial imagery for outdoor mapping. TU Graz has those available in their
room information system in several variants and formats for example.
We’ll focus on this below.
As always it’s important to make sure the material you use is available
under a suitable license and/or there’s an explicit permission for use for OSM mapping.
Using building plans in JOSM
Setup
While the following assumes you have JOSM set up and connected to your OSM account,
there’s additional plugins needed for this. Those can be installed via “Edit > Preferences… > Plugins”.
The main one is “PicLayer”, “measurement” will also come in handy in many cases.
When using JOSM via Flatpak you’ll likely also want to give it full file system permissions for this.
JOSM is based on Java Swing which has no support for XDG portals for accessing files. While that’s usually
not an issue when editing OSM data it wont be able to open local build plan images otherwise.
Building outline
Editing a building starts with identifying the building outline. In practically all cases that will
already exist in OSM, there might be cases with more than a single outline though, e.g. when a building
has different extents on different floors.
Besides the building plan, aerial imagery available in JOSM can be a useful reference here.
Building outline with aerial image background.
In the above example we see that the existing outline covers the building extent at its top floor, omitting
the parts on the ground floor towards lower right side as well as the small glass extension to the top.
That’s of course worth fixing on its own, and if the rooms you want to map are in that part of the building
it’s the first step anyway. It’s yet another topic though,
so for now we assume the part we want to map is covered by the existing outline.
Aligning the building plan
The next step is then to properly align the building plan image underneath the building outline, as that will
most likely neither be scaled nor rotated correctly after adding it via “Imagery > New picture layer from file…”.
After enabling the building plan layer to be the currently active one
(ie. it having the green checkmark in front of it in the “Layers” sidebar pane),
controls for manually scaling and rotating become available. That works, but can be
rather cumbersome to use.
Much more convenient is the automatic calibration feature of the PicLayer plugin. For this we need to know
the physical length of two lines of the building outline. Whether that’s read from the building plan, measured
in JOSM on the building outline or aerial imagery (which is where the measurement plugin comes handy), or measured
in real life doesn’t really matter.
Calibration can then be started via “Mode > PicLayer auto calibration” in the menu (again, make sure the building
plan layer is enabled), which gets you the following dialog.
JOSM PicLayer calibration dialog.
Follow that from top to bottom:
Select “Add points…” and click on three points on the building plan for which there are corresponding points
in the building outline.
The following two text input fields become enabled then, enter the physical length in meters between
point 1 and 2 as well as 2 and 3.
Click on the left “Select a layer including the building outline as reference…” and pick the OSM data layer
in the follow dialog, by default that’s called “Data Layer 1”.
Finally, select the “Add points…” action on the bottom, answer the following message box with “defined” (ie.
we already have an existing building outline), and then pick the three OSM nodes corresponding to the points
you selected on the building plan.
Completed calibration dialog.
With all that done, the “Run” action becomes available and if everything matches this results in the floor plan
being correctly position behind the building outline. The process can fail e.g. if the plan and the outline can’t
be made to match, e.g. because the measured values were wrong or the selected points weren’t actually the same.
To avoid having to go through this process multiple times, there’s actions in the context menu of the image
layer to save and restore the calibration data.
Mapping room geometry in JOSM
With the building plan correctly aligned we can start to add room geometry. As many buildings have
predominantly rectangular structures, enabling “Edit > Angle Snapping” once in “Draw Mode” tends to
be very helpful. That not only helps with producing 90° angles but it also provides guiding lines
for aligning e.g. multiple walls on a straight line.
In most cases the so-called “thin wall” model is used, that is walls between rooms are mapped as a
one-dimensional line rather than as two-dimensional geometry (“thick wall” model). Exceptions might
be very old buildings with very thick or irregular walls such as castles or cathedrals. While (visual)
renderers and routers would benefit from the higher level of detail of the “thick wall” model it poses
a big challenge for tactile renderers as those can only output a much reduced information density and
“pixel” resolution.
Alignment and angle guides in JOSM.
The bare minimum tagging on new geometry would need to be the level
tag containing the floor level and the indoor tag describing the general type of
structure (room, corridor or open area). There’s a lot more that could be added though
(see below), but that is often better and easier to do on-site.
Don’t forget to also map corridors and open areas as well as possibly missing pieces of outside walls.
Humans tend to automatically fill those in when looking at a map, but routers wont.
Mapping doors
Another thing that’s easiest to add from building plans are doors. Without those routers will steadfastly claim
rooms are impossible to enter.
Doors are generally mapped as points. So that’s a matter of clicking on their center on the room geometry
and tagging the resulting new node with indoor=door and the corresponding level as the bare minimum.
If a door is not meant to be used by the public, e.g. because it’s locked or because it’s an emergency exit,
that’s also crucial to tag as routers will otherwise happily exploit this new shortcut.
See access,
entrance and
exit for this.
Floor level changes
Structures that allows changing between floor levels (staircases, elevators, escalators, ramps, etc)
are also essential to tag as such, with the important part being the level tag containing
the set of floors reachable this way.
Without that routers wont find their way up or down a building.
And everything else
There is a whole lot more details that can be tagged on the new geometry then, such as:
Information about tactile_paving guides and
handrails, which are useful for people with reduced vision.
Adding all those details is much closer to outdoor OSM mapping and can also be done e.g. with mobile editors.
An editor that can do floor-level filtering is still useful, but you can get a long way there without touching geometry,
making this also a much more approachable activity for new OSM contributors.
Interested in more?
For some inexplicable reason you find all this super exciting and want to get more involved? No problem, there’s
plenty of opportunities:
halla
@kbroulik:kde.org
