Penpot WebGL and Bugfixes

• Penpot and WebGL
  • Penpot released their WebGL rendered (beta) for all users to test. This brought speed gains in rendering content on page and less lag when navigating. Frame rate was worked on and the overall interface appears faster. Pages load much faster than before, though there are still some rough edges. Overall, this is a gain for Ocean given it is a large design system.
  • This change also brought a sleuth of new bug reports for Penpot, you can see them here: https://github.com/penpot/penpot/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22IOP%20render%22
  • We also experienced a few issues around speed, borders missing, and incomplete rendering. Those were reported promptly.
  • From what I can see in their development page, there is going to be a 16.1 release with a few fixes for the rendering engine that should address the most pressing issues around speed and rendering accuracy.

• Issue with boolean shapes and Penpot crahes
  • It seemed for some time that the Penpot file for Ocean was crashing constantly. I wasn’t sure what the problem was but whenever there was an update to the tokens, the system would record the change and then crash.
  • After reviewing some of the error messages, it seemed that the problem was derived from shapes containing boolean operations. For example, the Date Picker component has a cutout circle (A difference boolean operation) to form the circular shape that highlights the current day. Those components appear left and right of the circular shape. Like half moons. These shapes were not flattened, they retained their boolean operation.
  • This is generally not an issue at all but it appears it was in Penpot. Once I identified the shapes with the boolean properties, I flattened them all to make sure they were no longer a problem, and then boom! The problem was gone.
  • However, one reason for keeping boolean operations in the components and not flattening is so that other designers can understand how some components are built and also have greater control over their design. When you flatten shapes, this makes it so that you loose the “how” a shape is built.
  • Even though crashing is resolved, it’s important to note that adding, editing, and removing tokens can take a long time.
    
• Issue with Input Fields and Badges Set to Static
  • Whenever one changes the base component at the root of the component, it seems that propagation is not always clean and some aspects of the component do not update as they should. Some values tend to go back to being static when you mean for them to use the fill or hug property.
  • It appears that some recalculations do not always yield the right result on the components.
  • They are aware of these problems and are working to address them.
  • This issue happened in some components where the text fields inside a nested component were suppose to have the fill property, but in their wrapped component setup, the base component text field showed static. This made is so that input fields looked longer than they should have inside other bigger components.
  • It took me a minute to update them all but it seems that now the input fields and badges should behave properly.
• After putting all these fixes in, I uploaded a new version of the Penpot file into gitlab so that others can update.

Figma Icon Flattening

• We still have the issue that we can’t bring our icons to Penpot just yet. As we build more and more UI concepts for Ocean inside Penpot, we need to rely on our new Ocean icons to make sure they convey the right message in context.
• I went back to the Figma file this week and created a copy of our monochrome icons and started the process of flattening them. This makes it so that it’s just a shape without layers or boolean operations. Just a raw flat svg file.
• This type of operation is supported in Penpot, though we lose the fine control.
• My desire is to bring some, if not all, of our monochrome icons into Penpot, even if they are flat, so that we can use them throughout our component UI more effectively.
• I am still exploring whether this is a good idea overall but this should add a few more images to the Penpot file. Expect the Penpot library to grow. This is an experiment to see how Penpot will handle this influx.

App Icons Progress

• Progress is moving slowly but surely. I went through a round of feedback review as I posted some of the icons into the VDG channel and also asked Nuno Pinheiro for feedback.
• There are a few more things that need to be done. As shown previously, the work of building colorful icons goes in phases. The current phase is intended to build colorful, “try anything”, higher fidelity icons. In this stage, shapes, colors, radii and other elements are placed on screen to see how they come across.
• From this stage, one would pick out the best icons and use them as design guidelines for other icons. You begin to restrict your color palette, harmonize shapes, shadows and other elements.
• This process will continue. My personal goal is to have a robust set of app icons for Akademy in September (https://akademy.kde.org). Then work with maintainers to get buy-in and feedback for the new designs.

Tokens and Plasma System Variables

• We follow the token naming convention used in Material Design 3. It’s expressed like this:
  • Raw value > Reference Token > System Token
• Plasma has its own set of variables used for various purposes. For example:
  • SpacingSmall, SpacingMedium, etc.
  • We need to find the way to do Raw value > Reference Token > System Token > SmallSpacing
• Even though the design system contains more tokens than there are variables in Plasma, we need to do the work of matching design tokens to Plasma. This should yield a workable set of UI changes even though it may not be complete.
• For those tokens that don’t have an equivalent in Plasma, we need to create an integration and support plan.
• For those design tokens that have approximations, we need to determine what is best, to accommodate to what we have in Ocean or to make Ocean accommodate to what the system already has.
• The biggest risk here is that if we change values in the system carelessly or introduce unsupported tokens, the applications using those variables in Plasma could break or work in a strange way.
• In this new age of Union work, we would parse design tokens via Union, this would produce the graphical interpretation of the token and apply it. Since Union is using CSS to interpret the values, token values and component values can more easily be replicated in Plasma.

 This year Qt Contributor Summit will be held in Oslo during late October.

If  you are a Qt contributor (developer, forum question answerer, promoter, etc) you should think of attending, it's always a great experience :)

More info in the announcement at https://www.qt.io/blog/qt-contributors-summit-2026-oslo-in-october 

If you want to attend do not forget to register (the earlier the better for the organizing team) following the form at https://wiki.qt.io/Qt_Contributors_Summit_2026 

Thanks to The Qt Company for organizing this and also to reMarkable for hosting!

The Amarok Development Squad is happy to announce the immediate availability of Amarok 3.3.3, the third bugfix release for Amarok 3.3 "Far Above the Clouds"!

3.3.3 features a number of small bugfixes, e.g. to saving of window and context applet layouts, inhibiting suspend during playback and updating of Wikipedia applet to handle current syntax. Additionally, small code quality improvements and fixes for building the software on different systems with various setups are included.

All in all, Amarok 3.3.3 keeps ensuring you can keep enjoying your music in 2026.

Changes since 3.3.2

CHANGES:

• Small code quality improvements and fixes for building on different systems

BUGFIXES:

• Restore functionality for inhibiting system suspend when music is playing
• Fix restoring main window layout after restart (BR 514963)
• Fix context applet height saving sometimes not working (BR 514190)
• Adapt parsing in Wikipedia applet to handle some page syntax changes
• Don't multiply tracks when dragging from file browser to PUD (BR 521425)

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.3 soon, as well as the flatpak available on flathub.

Packager section

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

Release 20 of the Qt Creator IDE adds support for working with AI coding agents, a Zen Mode that puts your code editor into the focus, support for the GN (Generate Ninja) build system, and many more improvements.

This is a weekly update from my Google Summer of Code 2026 project with KDE, improving effect widgets in Kdenlive, a free and open source video editor.

This week was driven entirely by reviewer feedback on MR !887; the draft MR for the Curves Widget.

Point snapping instead of rejection

When two curve control points are placed too close on the x-axis, avfilter/MLT crashes with Key point coordinates are too close or not strictly increasing.

The original guard in AssetParameterModel::internalSetParameter silently rejected the update, the user moved a point but nothing happened visibly. Reviewer Bernd Jordan flagged this as confusing UX.

The fix: instead of rejecting, snap the offending point so it maintains the minimum safe x-distance (~0.00266) from its neighbor. The curve is always valid, always sent to MLT, and the user sees immediate feedback.

Removing the 5 point limit for avfilter.curves

The curve editor had a maximum of 5 control points, inherited from frei0r.curves. JB pointed out there is no reason to keep this limit for avfilter.curves, it is a frei0r-specific constraint.

The fix: setMaxPoints is now only called for frei0r.curves. The avfilter.curves widget has no upper limit on control points.

Both fixes are in MR !887.

JB also noted the null placeholder approach in m_widgets for secondary av_curve params is not ideal long term, waiting on his direction before touching that.

This week, I worked on two things: a bug fix that was created during the ActionCollection port and starting the import/export feature.

Bug fix: Lock/Unlock action text:

A bug was created after !29 was merged. When a wallet was locked, the placeholder message displayed a "Lock" button instead of "Unlock". The issue came from ActionData using static text, while the lock action needs to reflect the wallet's current state. The fix was easy — switch between the lock and unlock ActionData dynamically based on the locked property.

AC.ActionCollection.action: locked ? "unlock" : "lock"

This was submitted as !31 and merged.

Configure Shortcuts menu item:

I added a "Configure Shortcuts…" menu item to the globalDrawer(!32), using AC.StandardActionData.KeyBindings to attach to the action automatically created by ActionCollectionManager.

Import/Export feature: I started implementing the import/export feature. The format is KWalletManager-compatible XML, so users can migrate between KWalletManager and KeepSecret. The implementation adds: -ImportExportManager C++ class with exportToFile() and importFromFile() methods. -Export… and Import… menu items in the globalDrawer. -File picker dialogs using QtQuick.Dialogs.

The merge request !33 is open and under review.

Even well-designed applications can become difficult to understand when their main workflows involve multiple controls, pages, or unfamiliar interaction patterns. Expecting users to discover these features on their own may lead to frustration, abandoned tasks, and additional support requests. Kirigami-Addons' onboarding module addresses this problem by presenting contextual guidance directly in the user interface, highlighting relevant elements and explaining them when they matter. When implemented through reusable and non-intrusive components, it can improve the user experience without requiring substantial changes to the existing application code.

Kirigami-Addons' onboarding module provides a complete set of features for defining and running contextual walkthroughs in Kirigami applications:

• Declarative steps: attach guidance text directly to existing QML elements without restructuring the interface.
• Source areas: define the UI region covered by a walkthrough and containing its onboarding steps.
• Automatic sequencing: visit steps according to their declaration order.
• Walkthrough groups: create multiple onboarding flows, such as basic and advanced tutorials, over the same interface.
• Conditional steps: disable individual steps dynamically; disabled or destroyed elements are skipped automatically.
• Visual highlighting: outline the current element while dimming and blurring the surrounding interface.
• Configurable appearance: adjust the highlight padding and the intensity and quality of the background blur.
• Adaptive tooltips: position guidance above, below, or within the available space around the highlighted element.
• Navigation controls: move forward or backward, or cancel the walkthrough, using buttons, keyboard shortcuts, or QML methods.
• Lifecycle hooks: prepare or restore the interface before a walkthrough or individual step is displayed.
• Dynamic interface support: navigate between pages, tabs, views, dialogs, or other containers before highlighting their elements.
• Custom content: add application-specific metadata and present images, animations, videos, or other QML content inside the onboarding tooltip.
• Responsive geometry tracking: keep the highlight synchronized when elements move, resize, or change parents’ positions.
• State monitoring: observe the active walkthrough, source, current step, guidance text, geometry, and navigation availability.
• Accessible navigation: provide accessible button labels, keyboard operation, right-to-left layout support, and platform-consistent styling.

Adding Onboarding to Your Kirigami Application

This section explains how you can add onboarding features to your Kirigami appplication.

Basic onboarding declaration

After importing the onboarding module, mark a common ancestor of the UI elements with Onboarding.isSource. This source defines the area where the module creates its overlay, applies the background effect, and searches for onboarding steps. Steps are declared directly on descendant elements using attached properties. Here, Onboarding.texts associates guidance with the Create project button, while Onboarding.start() begins the walkthrough. Steps are presented in declaration order, allowing onboarding to be added with minimal changes to the existing QML structure. You can use Onboarding attached properties to highlight/explain individual controls, layouts/groups, and even sub-controls.

Defining multiple onboarding workflows

The Onboarding.sourceGroups property declares the workflows available from a source area. The empty string represents the default workflow started by Onboarding.start(), while named groups, such as advanced, are started by passing their name to Onboarding.start().

Each step uses Onboarding.groups to select the workflows in which it participates. The entries in Onboarding.texts correspond by position to those groups, allowing the same UI element to provide different guidance in each workflow. In this example, Create project belongs to both workflows, while Enable version control appears only in the advanced one.

Extending onboarding tooltips with additional data

The Onboarding.additionalData property associates application-specific metadata with a step. In this example, the metadata provides an animated WebP and its caption. A custom component reads the current step through Onboarding.currentItem.additionalData and displays this content using AnimatedImage and Label. Finally, binding the component to Onboarding.additionalDataComponent inserts it into the default tooltip between the guidance text and navigation controls, allowing applications to enrich onboarding steps without replacing the complete tooltip implementation.

Examples

This is the example tutorial included in the Kirigami Addons repository. It demonstrates how the onboarding module can highlight individual controls, groups of controls such as layouts, and even sub-controls. It also shows how to attach additional data to onboarding steps, such as a video and its caption, and how to define multiple onboarding workflows within the same application.

And this is the onboarding module in Minuet: a short guided walkthrough that highlights the most important parts of the exercise screen, explains what each control does, and helps new users understand the flow without leaving the application.

The onboarding module provides a declarative and non-intrusive way to introduce users to important controls and workflows in Kirigami applications. With support for multiple workflows, dynamic interfaces, custom tooltip content, lifecycle hooks, and configurable visual effects, it can address both simple guidance and more advanced onboarding scenarios.

A possible direction for future work is allowing each onboarding step to wait for a specific user interaction before continuing. Instead of relying only on the Next button, a step could advance after the user clicks a highlighted control, changes a value, or completes an expected action. This would extend the module beyond explanatory walkthroughs and enable fully guided, interactive tutorials in which users learn application workflows by performing the actual operations.

Give the module a try in your application and share your experience, suggestions, and use cases. Feedback is especially welcome while these APIs are still being refined for an upcoming Kirigami Addons release.

For almost two decades, the PackageKit package management abstraction layer has shipped with pkcon as its command-line client. pkcon does its job, but it was always kind of a “testing” front-end for the PackageKit daemon rather than a tool designed for everyday use. The focus has instead been on the GUI tools, automatic system updates, GUI application managers and other front-ends. Its command names mirror the D-Bus API almost one-to-one (get-details, get-updates, get-depends), output is very plain, and there is no machine-readable mode for scripting. Most importantly though, there has been no development on it at all for almost a decade, so pkcon was stuck in its rudimentary state from that era.

Since a lot of changes will be coming to PackageKit, and testing the daemon and working with it from the command-line was not very pleasant anymore in 2025/2026, I decided to modernize the tool as part of my work as fellow for the Sovereign Tech Agency last year. pkgcli is the new command-line client for PackageKit. It is built from the ground up to be pleasant to use interactively and easy to drive from scripts.

Why a new tool?

Of course, instead of introducing a new tool, I could have just expanded pkcon instead. The problem with that approach is that the pkcon utility has been around for so long and its command-line API had ossified so much, that rather than changing it and potentially breaking a lot of scripts relying on its quirks, I decided to introduce a new tool instead. pkcon can still be optionally compiled for people who need it in their scripts and workflows.

The goals for pkgcli, and the features it now has are:

• Human-friendly command names. Verbs that read the way you’d describe the task, instead of mirroring the D-Bus API 1:1: show, search, list-updates, what-provides, instead of get-details and friends.
• Readable, colored output by default (still respecting NO_COLOR and degrading gracefully).
• A real scripting mode. A global --json flag emits JSONL instead of fully human-readable output when possible, to make it easier to use the tool for scripting purposes.
• Sensible defaults. A few defaults have been changed, such as the metadata cache-age, or automatic cleanup of unused dependencies being enabled by default. This is more in line with current defaults by other tools and frontends. We also print package information in a slightly different, more readable way.
• Better handling of internationalized text. Text should now align properly in the terminal window, and we should no longer have completely chaotic text output on non-English locales (especially Chinese/Japanese).

Why not pkgctl?

Originally, this tool was called pkgctl, to match other common cross-distro tool names. However, that name was already taken by an Arch-specific distro development tool. When this issue was raised, we decided to just rename our tool to pkgcli with the next release, to avoid the name clash on Arch Linux.

Examples!

Here are some examples on how to use the new tool (some of which include the abridged output pkgcli prints).

Search for anything containing the string “editor” in name or description, then look at the details of one result:

$ pkgcli search editor
Querying                  [████████████████████████████████████████] 100%
▣ ace-of-penguins 1.5~rc2-7.amd64 [debian-testing-main]
▣ acorn-fdisk 3.0.6-14.amd64 [debian-testing-main]
▣ ardour 1:9.2.0+ds-1.amd64 [debian-testing-main]
✔ audacity 3.7.7+dfsg-1.amd64 [manual:debian-testing-main]
✔ audacity-data 3.7.7+dfsg-1.all [auto:debian-testing-main]
▣ augeas-tools 1.14.1-1.1.amd64 [debian-testing-main]
▣ emacs 1:30.2+1-3.all [debian-testing-main]
▣ gedit 48.1-9+b1.amd64 [debian-testing-main]
▣ gedit-common 48.1-9.all [debian-testing-main]
▣ gedit-dev 48.1-9+b1.amd64 [debian-testing-main]
[...]

$ pkgcli show nano
Package: nano
Version: 9.0-1
Summary: small, friendly text editor inspired by Pico
Description: GNU nano is an easy-to-use text editor originally designed as
 a replacement for Pico, the ncurses-based editor from the non-free mailer
 package Pine.
[...]
URL: https://www.nano-editor.org/
Group: publishing
Installed Size: 2.9 MB
Download Size: 646.0 KB

Search only within package names rather than descriptions:

$ pkgcli search name python3

Check for updates. refresh updates the metadata, then list-updates reports what’s available:

$ pkgcli refresh && pkgcli list-updates
Loading cache            [████████████████████████████████████████] 100%
▲ cme 1.048-1.all [debian-testing-main]
▲ gir1.2-gdm-1.0 50.1-2.amd64 [debian-testing-main]
▲ imagemagick 8:7.1.2.24+dfsg1-1.amd64 [debian-testing-main]
▲ imagemagick-7-common 8:7.1.2.24+dfsg1-1.all [debian-testing-main]
▲ imagemagick-7.q16 8:7.1.2.24+dfsg1-1.amd64 [debian-testing-main]
▲ libdlrestrictions1 0.22.0.amd64 [debian-testing-main]
▲ libfftw3-bin 3.3.11-1.amd64 [debian-testing-main]
▲ libfftw3-dev 3.3.11-1.amd64 [debian-testing-main]

Explore relationships between packages:

$ pkgcli list-depends inkscape  # list what inkscape depends on
$ pkgcli list-requiring libappstream5  # list what requires libappstream5

Find the package that provides a capability, here the AV1 GStreamer decoder:

$ pkgcli what-provides "gstreamer1(decoder-video/x-av1)"
✔ gstreamer1.0-plugins-bad 1.28.3-1.amd64 [auto:debian-testing-main]

You can also have JSON output for most commands! Attach --json to any query and pipe the result straight into jq. Each line is a self-contained JSON object:

$ pkgcli --json list-updates | jq -r '.name'
cme
gir1.2-gdm-1.0
imagemagick
imagemagick-7-common
imagemagick-7.q16
libdlrestrictions1
libfftw3-bin
libfftw3-dev
libfftw3-double3

Try it

pkgcli is built by default alongside the rest of PackageKit since PackageKit 1.3.4. If your distribution ships a recent enough PackageKit, it should already be on your PATH. You can read its man page man pkgcli for more information. Feedback, bug reports, and patches are very welcome.