In this rather lengthy post I talk a bit about the current issues with icons for the KDE applications I work on or use.

Let’s start with looking at what I mean with KDE applications and what the current state is, up to KDE Frameworks 6.2 and current KDE Gear 24.02. Then let’s see what will be improved in future releases.

What do I mean with ‘KDE Applications’

#

If I speak about ‘KDE Applications’ here I talk about applications like Kate, Dolphin, Okular and others like that.

This means applications developed with Qt and KDE Frameworks that integrate well with the KDE Plasma desktop but are not restricted to it.

Many of this applications not just aim to work well on Linux & BSD or other open source operating systems but are ported and working well on the rather different Windows and macOS desktop. Some even are successful since years in the official Windows Store.

The above applications are part of the KDE Gear releases, but the described issues and solutions naturally are not restricted to stuff released with that.

What most of these applications have in common is that they rely on rather large parts of our Frameworks. With that they depend at least indirectly on an icon set that covers large parts of what our default icon set Breeze provides. Even if you use no icons from that icon set yourself in your application, just using the standard actions or many widgets/dialogs from Frameworks will rely on some subset of Breeze.

Current State of Icons per Desktop or Platform

#

When talking about the current situation of icons that depends largely on the desktop or platform you are running the KDE application on.

Let’s take a look at some (I for sure miss some that are common or loved, that doesn’t mean I disregard them, I just want to limit the scope).

KDE Plasma on Linux/BSD with Wayland/X11

#

If you just aim to run on the KDE Plasma desktop with your Qt and KDE Frameworks based application, all is fine with icons, there is no problem.

The KDE project did their job, at least for Kate I never did have any issues with icons on Plasma.

Below a screenshot of Kate 24.02 running on Plasma 6. All icons are there, they are properly re-colored for the dark theme, too, including not just the used Breeze icons but for example the small Git icons in the left sidebar that Kate has bundled.

This is the vanilla state each user will get if Kate is installed on Plasma (and the dark theme is used). There are no patches done during building to achieve that nor is there any extra user configuration necessary.

Microsoft Windows

#

If you run Kate on Windows, the icon situation is good, too, if you use our Windows Store variant or get at build done via Craft.

See below what the current nightly of Kate looks like in some Windows 11 VM (I just started it from the unpacked ZIP, no setup needed).

In the Craft build descriptions we do some patches to ensure the Breeze icons are bundled as library and the application links with that. In addition we ensure with some more patching that our own icon engine is used to allow for the proper recoloring.

If you don’t do that patching you will end up with close to no icons or for dark theme black on black icons.

Apple’s macOS

#

The situation on macOS is the same as on Windows.

If you go with a Craft build of Kate, you will end up with something like below.

All icons are there and even application provided icons like our Git one are properly recolored.

Without the Craft patches Kate has more or less no icons like on Windows.

Haiku

#

After covering Plasma and the two large closed-source desktop operating systems, as a small excursion, look how Kate (the KF5 based version) looks if installed on Haiku with the package they provide.

Kate looks ok, system icons intermixed with Breeze as fallback icons.

GNOME

#

For testing this, I installed the latest Fedora Workstation in a VM. I have done no user configuration beside what the installer and initial setup wizard asked and then just installed the Kate package. The shell was even helpful to ask to do that after you just tried to start the not installed Kate.

Most icons not there, not that nice. For details about that read this post, we don’t need to re-iterate this again.

If you think: that is just Kate, let us just try Okular.

One thing that can be at least solved easily is that the icons are gone, we just install the Breeze icon set as package.

Looks ok, system icons intermixed with Breeze as fallback icons just like on Haiku. Not stylish but usable.

I was unable to trigger Kate or Okular to adjust to the dark mode GNOME provides, therefore I can not test if we end up with black on black icons there, but it is likely, as the fallback is just Breeze.

MATE

#

Kate and Dolphin 24.02 on MATE with dark mode on NixOS, normal system packages, Breeze icons is installed.

System icons intermixed with Breeze as fallback icons, looks not that nice. Breeze icons not readable, as recoloring is not working.

Xfce

#

Kate and Dolphin 24.02 on Xfce with dark mode on NixOS, normal system packages, Breeze icons is installed.

Same mix and unreadable state as on MATE.

Enlightenment

#

Kate 24.02 on Enlightenment with dark mode on NixOS, normal system packages, Breeze icons is installed.

Just unreadable icons, beside out own Git icon and the few colored ones.

Summary: What’s up with Icons today

#

The icons in KDE applications do look perfect on KDE Plasma. That should be no real surprise as many people working on these applications will test them there and KDE Frameworks and Qt are well tested on Plasma, too.

The icons look fine on Windows and macOS, too, at least for applications that got properly ported, but only thanks to patches we do in Craft. If you just grab e.g. Kate’s and the needed frameworks sources from our normal repositories, you don’t get that.

If the maintainers of the port for some OS do care, like the Haiku people, KDE applications can look fine there.

On other desktop environments it doesn’t look that great out of the box.

Unlike for the other operating systems, there the same packages without extra patches are running.

Whereas that works perfect on Plasma, we rely too much that the desktop environment running provides an icon set that has a similar coverage and naming as Breeze. As we don’t hard depend on the Breeze icons for our applications, it can even happen that just no fitting icons are there per default.

Even if that can be solved with some better package dependencies, you still end up with a patchwork look and without a Qt platform theme plugin that handles the needed recoloring to make dark mode feasible.

Getting it fixed

#

Fortunately, just because the status quo is not that nice, it must not stay that way.

We have more or less all needed parts to fix the situation, we did already fix it during the porting to Windows and macOS.

We just never pushed to get this stuff done on Linux and Co.

How did we solve it there?

• We have the Breeze icon set as Qt resource inside a library and link with that. That makes them a hard build and runtime dependency and easy to deploy.
• We ensure the icon engine we have in our KIconThemes framework is there and used.
• We enforce the Breeze Qt style. (this is not really icon related, but ensures an usable look’n’feel, too)

The first and the last thing are easy to do on Linux and Co., too, even with still allowing the user to override the icon set and style, but still defaulting to Breeze.

The second point is harder, as that requires at the moment a few hacks and is not 100% as good as going the Qt platform theme plugin route we use inside Plasma.

For KDE Frameworks 6.3 we worked to get that done.

See our meta issue on our GitLab instance covering that topic.

All is not perfect, we will need to get some Qt API to fully do that, but the current state is already usable.

Here a comparison with the state as we have it now in our released software compared to with the state in the current master branch on an Cinnamon desktop.

The left side is the current Kate 24.02, the right side the current master build of Kate with master Frameworks.

The hard dependency to the Breeze icon library is done in KIconThemes, if you link to that, you are guaranteed that you have Breeze icons. You can naturally just link to only the Breeze icon library on your own.

The ensuring that the proper icon engine is done with some new API in KIconThemes that application developers must opt-in for. The same for the Qt style setup, there we have API in KConfigWidgets.

For Kate the concrete changes can be found here. They are minimal and even remove some platform specific code for the style setup.

Including fallback code for pre 6.3 Frameworks compatibility of the style setting, the basic idea is:

#include <KIconTheme>

#define HAVE_STYLE_MANAGER __has_include(<KStyleManager>)
#if HAVE_STYLE_MANAGER
#include <KStyleManager>
#endif

int main(...)
{
    /**
     * trigger initialisation of proper icon theme
     */
#if KICONTHEMES_VERSION >= QT_VERSION_CHECK(6, 3, 0)
    KIconTheme::initTheme();
#endif

    QApplication yourAppInstance(...);

#if HAVE_STYLE_MANAGER
    /**
     * trigger initialisation of proper application style
     */
    KStyleManager::initStyle();
#else
    /**
     * For Windows and macOS: use Breeze if available
     * Of all tested styles that works the best for us
     */
#if defined(Q_OS_MACOS) || defined(Q_OS_WIN)
    QApplication::setStyle(QStringLiteral("breeze"));
#endif
#endif

    ...
}

In the long run, once 6.3 is the minimal version the application depends on, this is just:

#include <KIconTheme>
#include <KStyleManager>

int main(...)
{
    /**
     * trigger initialisation of proper icon theme
     */
    KIconTheme::initTheme();

    QApplication yourAppInstance(...);

    /**
     * trigger initialisation of proper application style
     */
    KStyleManager::initStyle();

    ...
}

At the moment KIconTheme::initTheme() is still a bit hacky until we have proper Qt API, but that is not visible for the API user.

If we get this properly done in our applications, that will not just solve the current issue for running them in other desktop environments.

With that API in use and the now already upstreamed patches, one can build vanilla Frameworks and Kate on Windows and macOS and the icons will just work in the resulting application bundles and you get an usable style out of the box if Breeze is there.

Help Wanted!

#

We have now some API to help our applications to be more usable on non-Plasma installations and Windows and macOS.

We still need to make use of it and we need to improve the implementation and upstream to Qt the needed extra API to make it a real 100% replacement to what we do with the Plasma integration plugin.

If you have time to help us, show up on our meta issue.

Not just coding is needed, we for example have still a few icons that don’t recolor well, help to fix that is wanted, too.

Feedback

#

You can provide feedback on the matching KDE Social or reddit post.

Hello Planet KDE!

I will be participating in Google Summer of Code this year adding Python support to a subset of the KDE Frameworks. You can follow my progress on this blog.

Since the last two posts about this topic (part one, part two) there has been some more progress, so let’s take a look.

Brightness Control

In Plasma 6.0, when HDR is enabled, you get to choose the brightness of SDR content in the display settings:

This is however not convenient to change quickly and doesn’t apply to HDR content, which so far is always presented at 100% brightness. In Plasma 6.1, you’ll be able to use the same ways to control brightness as on laptops or with displays that support DDC/CI in SDR mode: Just drag the brightness slider, press keyboard shortcuts or scroll on the brightness icon in the system tray, and it’ll dim the whole screen like you’d expect.

Powerdevil unfortunately only supports controlling the brightness of a single screen right now, and that limitation also applies here. The API it uses to communicate with KWin is per display though, so once powerdevil supports multiple screens, it’ll work for HDR displays too.

More accurate colors without a Colorimeter

Many new displays have a color gamut much wider than sRGB, and assume that their input signal is fitting for their color gamut - which means that, unless you use an ICC profile, colors will be much more saturated than they should be. There’s a few ways to correct this:

• find an sRGB option in your monitor’s OSD. This is usually pretty accurate if it’s available, but also limits all apps to sRGB
• buy a Colorimeter and profile your display. That costs money though, and the display profiling situation on Linux isn’t in great shape at the moment (DisplayCAL on Flathub is 4 years old, my last attempt at building it on Fedora didn’t work, and it only works correctly on Xorg atm)
• find an ICC profile for your display on the Internet and use that, hoping the display doesn’t deviate too much from the one that was profiled

There is a fourth option though: Use the color information from the display’s EDID. In Plasma 6.1, you can simply select this in the display settings.

Note that it comes with some caveats too:

• the EDID only describes colors with the default display settings, so if you change the “picture mode” or similar things in the display settings, the values may not be correct anymore
• the manufacturer may not measure every panel and just put generic values for the display model into the EDID
• the manufacturer may put completely wrong values in there (which is why this is disabled by default)
• even when correct values are provided, ICC profiles have much more detailed information on the display’s behavior than the EDID can contain

So if you care about color accuracy, this is not a way out of getting a Colorimeter and profiling your display… but if you just have two screens and you’re annoyed that one of them has much more intense colors than the other, this option is an easy and fast way to fix it.

Gamescope

Joshua Ashton implemented a new backend in gamescope, that uses Wayland subsurfaces to forward content to the host compositor instead of compositing it all into one image, and includes direct support for the frog_color_management_v1 protocol. The result of this is that with a new enough gamescope you don’t have to use any Vulkan layers to have gamescope pass HDR content to KWin, and you don’t have to use the --hdr-debug-force-output option anymore. If you want to play a game in HDR, you can now just put

gamescope -W 5120 -H 1440 --hdr-enabled --fullscreen -- %command%

into its launch options in Steam (with width and height adjusted to your screen ofc) and you’re done.

The backend also reduces the image copies made in comparison to the previously default SDL backend; the game’s buffers are directly passed to the host compositor, in most cases even while overlays are visible.

GPU Drivers

The driver situation is something I’ve been kind of ignoring in previous posts, but it’s obviously pretty important. First, let’s talk about the KMS API for setting a display into HDR mode. It consists of two parts:

• the HDR_OUTPUT_METADATA property, which compositors use to set mostly brightness related metadata about the image, like which transfer function is used and which brightness and color values the content roughly contains
• the Colorspace property, which compositors use to set the colorspace of the image, so that the display interprets the colors correctly

When you enable HDR in the system settings in Plasma, KWin will set HDR_OUTPUT_METADATA to the Perceptual Quantizer transfer function, and the brightness and mastering display properties to almost exactly what the display’s EDID says is optimal. This is done independently of the actual image content or what apps on the screen tell the compositor, to prevent the display from doing dumb things like dimming down just because an HDR video you opened claims it wants to display a supernova in your living room.

The one exception to that is the max_cll value - the maximum brightness of any pixel on the screen. It’s set to the maximum average brightness the display can show, because my Samsung C49RG94SSR monitor reduces the backlight brightness below SDR levels if you set the max_cll value it claims is ideal… With that one exception, this strategy has worked without issues so far.

On the Colorspace front, KWin sets the property to Default in SDR mode, and to BT2020_RGB when HDR is enabled. Sounds simple enough, but it’s of course actually more complicated.

Like any API that didn’t actually get used in practice for a very long time (if ever), both the API and the implementations were and are quite broken. The biggest issues I’ve seen so far are:

• AMD’s implementation of the Colorspace property for DisplayPort was broken, which caused colors to be washed out in HDR mode (fixed in Linux 6.8)
• the NVidia driver doesn’t force a modeset when HDR_OUTPUT_METADATA changes the transfer function or Colorspace changes its value, which causes temporary glitches when enabling HDR on some displays
• the Intel driver claims to support both properties for HDR laptop displays, but the implementation is missing entirely (this is being worked on)
• the Colorspace property implementations from Intel and NVidia cause washed out colors on many displays, because the API requires the compositor to change the property value depending on whether or not communication with the display uses RGB or YUV encoding… which the compositor doesn’t actually know anything about. The AMD implementation works around this by translating the property to the correct value in the kernel
• multiple laptop- or display specific issues that you can look up in the bug trackers if you want to

To summarize, if you want to use HDR, it’s best to use an AMD GPU with either kernel 6.8, or if you really must use an older kernel, HDMI. Even then, you might still see issues in some cases though - if you do, please make bug reports about it! Neither driver nor compositor developers can fix what they don’t know is broken.

What’s next?

As always, for every bit of progress made or feature implemented, there’s ten more upcoming exciting things that could be talked about or worked on… but the big next topic is offloading of color management tasks to the GPU’s scanout hardware, to save power and improve performance. Next week I’ll be attending the 2024 Linux Display Next hackfest, which will focus on exactly that, so stay tuned!

In a previous post I talked about using the QML Language Server for KDE development. Since writing that post a few things happened, so it’s time for an update.

I mentioned that when using Kate qmlls should work out of the box when opening a QML file. That’s mostly true, there is one problem though. Depending on your distribution the binary for qmlls has a different name. Sometimes it’s qmlls, sometimes qmlls6 or qmlls-qt6. You may need to adjust the LSP Server settings in Kate to match the name on your system.

In order for qmlls to find types that are defined in your application’s C++ code those must not only be declaratively registered, qmlls also needs to be told where to find the type information. Fortunately Qt 6.7 comes with a handy way to do that. By passing -DQT_QML_GENERATE_QMLLS_INI=ON to CMake you get an appropriate config file generated. This will be placed into the project’s source directory but is specific to your setup, so add that to your gitignore file (PS: You can set up a global gitignore file for your system, so you don’t need to add this to all your projects). Unfortunately the initial implementation produced wrong configurations for some modules, but this is fixed in Qt 6.7.2.

A problem I mentioned is that qmlls doesn’t find modules that are not installed into the same path as Qt. With Qt 6.8 there will be two new options. The -I parameter allows to add custom import paths to qmlls’ search paths. The -E parameter makes qmlls consider the value of the QML_IMPORT_PATH environment variable for its search paths.

In order for qmlls to work properly modules need to be created using the CMake API and use declarative type registration. Since writing the last post some KDE modules have been converted to those, but there’s still more to do.

Thanks to the QML team for those swift improvements!

Let’s go for my web review for the week 2024-19.

Heat Death of the Internet - takahē

Tags: tech, internet, web, satire, criticism

Obviously a satire, some of it feels eerily real though.

https://www.takahe.org.nz/heat-death-of-the-internet/

“AI now beats humans at basic tasks”: Really?

Tags: tech, ai, machine-learning, gpt, research, benchmarking, criticism

Nice article. It’s a good reminder that the benchmarks used to evaluate generative AI systems have many caveats.

https://aiguide.substack.com/p/ai-now-beats-humans-at-basic-tasks

Did GitHub Copilot really increase my productivity?

Tags: tech, ai, copilot, productivity

Interesting data point. This is a very specialized experience but the fact that those systems are kind of random and slow clearly play a good part in limiting the productivity you could get from them.

https://trace.yshui.dev/2024-05-copilot.html

AI Copilots Are Changing How Coding Is Taught - IEEE Spectrum

Tags: tech, ai, copilot, ethics, programming, teaching, learning

Well, maybe our profession will make a leap forward. If instead of drinking the generative AI cool aid, if we really get a whole cohort of programmers better at critical skills (ethical issues, being skeptical of their tools, testing, software design and debugging) it’ll clearly be some progress. Let’s hope we don’t fall in the obvious pitfalls.

https://spectrum.ieee.org/ai-coding

Machine Unlearning in 2024 - Ken Ziyu Liu - Stanford Computer Science

Tags: tech, ai, machine-learning, gpt, copyright, gdpr

Interesting questions and state of the art around model “unlearning”. This became important due to the opacity of data sets used to train some models. It’ll also be important in any case for managing models over time.

https://ai.stanford.edu/~kzliu/blog/unlearning

Systemd heads for a big round-number release [LWN.net]

Tags: tech, linux, systemd

Indeed the next systemd release feels feature packed. Definitely to keep an eye on.

https://lwn.net/SubscriberLink/971866/f244aee59d4d6a66/

UEFI, BIOS, and other confusing x86 PC (firmware) terms

Tags: tech, bios, uefi, hardware

Confused? Well, not surprising we mostly use those terms with very lax definitions.

https://utcc.utoronto.ca/~cks/space/blog/tech/UEFIAndBIOSAndOtherPCTerms

It’s always TCP_NODELAY. Every damn time. - Marc’s Blog

Tags: tech, tcp, networking

Getting network protocols right is definitely difficult.

https://brooker.co.za/blog/2024/05/09/nagle.html

Why Full Text Search is Hard

Tags: tech, language, search

If you wonder why information retrieval from natural language texts is a tough domain, here is a short article listing the important things to keep in mind.

https://transactional.blog/blog/2023-why-full-text-search-is-hard

All error messages are necessarily bad to some degree

Tags: tech, failure, ux

Not a reason to make no effort into having as proper error messages as possible. Still there’s some truth there that trying to have a really useful error message is a fool’s errand.

https://www.haskellforall.com/2024/05/all-error-messages-are-necessarily-bad.html?m=1

pyspread

Tags: tech, python, qt, spreadsheets, tools

Looks like a fun spreadsheet tool where you can use Python in any cell.

https://pyspread.gitlab.io/

The UX of UUIDs | Unkey

Tags: tech, uuid, encodings

Interesting set of tricks around UUIDs to make them easier to manipulate.

https://www.unkey.com/blog/uuid-ux

Build your own HTMX

Tags: tech, web, frontend, htmx

Excellent exercise in understanding how HTMX works under the hood.

https://joshi.monster/posts/build-your-own-htmx/

No, I don’t want to fill out your contact form - Adam Jones’s Blog

Tags: tech, web, email

Good exploration of the many ways contact forms fail us regularly. Also shows a few cases where you might still want to us them… in most cases you shouldn’t.

https://adamjones.me/blog/dont-use-contact-forms/

What You Need to Know about Modern CSS (Spring 2024 Edition) – Frontend Masters Boost

Tags: tech, web, frontend, css

Looks like a good reference about everything which can be done with the latest CSS evolutions.

https://frontendmasters.com/blog/what-you-need-to-know-about-modern-css-spring-2024-edition/

Google Testing Blog: Test Failures Should Be Actionable

Tags: tech, tests

Good advice indeed. Having asserts using appropriate matchers can go a long way understanding what went wrong.

https://testing.googleblog.com/2024/05/test-failures-should-be-actionable.html?m=1

Simplicity is An Advantage but Sadly Complexity Sells Better

Tags: tech, complexity

Definitely this. We tend to like complexity too much as a profession and field. It’s also a good reminder that the complexity of the problem and the complexity of the solution shouldn’t be conflated.

https://eugeneyan.com/writing/simplicity/

Programming mantras are proverbs - lukeplant.me.uk

Tags: tech, programming, culture, craftsmanship

Interesting take about the mantras often used in our profession. They shouldn’t be treated as laws, but as proverbs carrying a piece of contextual wisdom. It’s thus unsurprising that they tend to contradict each other. This contradiction should make us pause and think.

https://lukeplant.me.uk/blog/posts/programming-mantras-are-proverbs/

Refactor: Inline-Adjust-Extract - XP123

Tags: tech, programming, refactoring

Since there’s a clear tendency in the developers I meet to “extract at all costs”, this is a good reminder that sometimes you need to inline the code first. This very often brings better clarity in the context of use. In turns this leads to a better final extraction.

https://xp123.com/refactor-inline-adjust-extract/

Bye for now!

Kirigami Addons 1.2 is out with some accessibility fixes and one new component: FloatingToolBar.

Accessibility

During the accessibility sprint, there was an effort to ensure the date and time pickers were actually accessible. Aside from improving the screen reader support, this also allow to write Selenium integration tests which uses these components in Itinerary. Thanks Volker, David Redundo and others for working on this!

FloatingToolBar

Mathis and I worked on a new addition to Kirigami Addons adding to the existing FloatingButton and DoubleFloatingButton components. This component is perfect to add tool to editing and drawing areas and can either contain a simple RowLayout/ColumnLayout containing ToolButtons or a Kirigami.ActionToolBar.

import org.kde.kirigamiaddons.components
import org.kde.kirigami as Kirigami

FloatingToolBar {
 contentItem: Kirigami.ActionToolBar {
 actions: [
 Kirigami.Action {
 ...
 }
 ]
 }
}

Dialogs

With the style used by FormCardDialog and MessageDialog merged in Kirigami and soon in qqc2-desktop-style too, I did some changes to the FormCardDialog and MessageDialog to use the same padding as Kirigami.Dialog.

MessageDialog now works better on mobile with the layout adapting itself to the dialog size.

Aditionally similar to KMessageBox, MessageDialog has an optional “don’t show again” option which can be enabled by setting the dontShowAgainName property similar to the KMessageBox api.

I also prepared these two components to work as standalone windows which is likely to come with this Qt 6.8 change request.

CategorizedSettings

Jonah fixed a bug where it would be impossible to escape the settings on mobile.

Documentation

I added more screenshot to the API documentation and updated the TableView example app to use a ‘frameless’ style.

Qt 6.7 support

This release also brings support for Qt 6.7 on Android as this release introduced an API and ABI change to the Android code. Thanks Joshua for tackling this issue.

The new Ubuntu LTS was released in April, congratulations to all involved with that. I know Scarlett worked hard to get Kubuntu back into shape so do if that a try if you want a stable Plasma 5 desktop.

In the KDE neon project we don’t like to sit still for long so we are now building all our KDE packages on Ubuntu Noble, versioned 24.04. This always takes longer than it feels like it should, mostly because it’s a moving target to keep everything compiled as more KDE software gets released, so no promises on when it’ll be ready but we’ll try to be fast because the old Ubuntu base of jammy (22.04) is showing its age with projects like Krita no longer able to compile there.

So far the main issues are all the changes needed for 64-bit time_t to fix the y2k38 problem, we know you wouldn’t want your clocks to zero out in 2038.

KDE has a symbiotic relationship with many linux distros, since while we develop our software we also use particular versions of linux, I personally use archlinux as my distro of choice for many years being the only distro that I manage to bare for more than six months ( and I believe I am using it for more than 15 years already so that counts).

The "recipe" for packaging KDE software for arch is big, because we are big, and packaging large amounts of software is no easy feat, so me and Antonio Rojas started to update the build scripts to be less manual and less error prone. All the versions of Plasma 6 that have been packaged for arch are using this scripts in one way or another (or manually when we broke everything :)

This work is being done in a separate branch to not break the current workflow, but things are looking good and we hope to merge this in master soon, so that deploying newer versions of KDE software for arch will be a single command, meaning more time for the developers and less time creating packages.

KGraphViewer 2.5.0 has been just released! The main focus of this release is the port to Qt6 and KDE Frameworks 6 as well as general code modernisation, but of course some bugs have been squashed too. The full changelog can be found below.

About KGraphViewer:

KGraphViewer is a Graphviz DOT graph file viewer, aimed to replace the other outdated Graphviz tools. Graphs are commonly used in scientific domains and particularly in computer science.

You can learn more at https://apps.kde.org/kgraphviewer/

URL: https://download.kde.org/stable/kgraphviewer/2.5.0/
SHA256: 872bee63fb4df6f7fb2b4eaf02ff825cba3ca953ac02509a287fe5cd0f1e2b69
Signed by: D81C 0CB3 8EB7 25EF 6691 C385 BB46 3350 D6EF 31EF Heiko Becker heiko.becker@kde.org
https://invent.kde.org/sysadmin/release-keyring/-/raw/master/keys/heikobecker@key1.asc

Full changelog:

• appstream: Add upcoming 2.5.0 release
• Brush up menu & action terms a bit
• Add icons to more actions & submenus
• Update homepage URL in README
• Remove some outdated/unused files
• Avoid double look-ups in maps, use iterator returned from find method
• Add widget parent to QMenu instances
• DotGraphView: create popup menu only on demand
• Share also zoom actions between DotGraphView & KGraphViewerPart
• Use enum QColor constructor instead of string based one
• Use KStandardAction convenience creation methods, parent all to collecitions
• Drop file_open_recent from ui.rc files, given KStandardAction toolbar magic
• Use more member-function-pointer-based Qt signal/slot connects
• Port away from auto-casting from ascii strings
• Fix missing closing tags in D-Bus API xml files
• Use QList directly instead of Qt6-times alias QVector
• Make manual build & install fully optional
• Update links to graphviz website
• Fix handling file cmdl arguments with relative path
• Fix bad defaults for fonts, also for colors, shapes & style
• KGraphViewerPart CMake config file: drop KGraphViewerPart_INCLUDE_DIRS
• Bump version & SO version for first Qt6-based release
• Drop support for Qt5/KF5
• Clean up includes & forward declares
• Do not use Qt modules includes
• Deploy custom pixmaps as Qt resource
• Printing page settings: remove custom broken window icon
• Printing page settings: replace "lock ratio" button with checkbox
• KGraphViewer KPart metadata: use normal app display name as name
• Drop libkgraphviewer appstream file, no other libraries provide some
• Set target properties right after declaring the target
• Remove unused version header includes
• Drop code for no longer supported KF versions
• Fix another wrong min Qt version variable name usage
• Use ECMDeprecationSettings
• Port away from deprecated QMouseEvent::globalPos()
• KGraphEditor: fix bad port to QMessageBox::question
• Use Q_EMIT instead of emit
• Switch to ECM required-default KDE_COMPILERSETTINGS_LEVEL
• Remove unneeded ; after Q_DECLARE_PRIVATE() & Q_DECLARE_PUBLIC()
• Use more nullptr
• Fix wrong min Qt version variable name usage
• Add Qt6/KF6 build support
• Remove unneeded QApp::setOrganizationDomain, dupl. KAboutData::setApp...Data
• appdate: use desktop-application type, add developer & launchable tags
• Update homepage to apps.kde.org
• Port away from deprecated QDesktopWidget
• Port away from deprecated QPrinter::setOrientation()
• Port away from deprecated QPrinter::numCopies()
• Port away from deprecated operator+(Qt::Modifier, Qt::Key)
• Port away from deprecated QWheelEvent::delta()/orientation()
• Port away from deprecated signal QButtonGroup::buttonClicked(int)
• Port away from deprecated I18N_NOOP2
• Port away from deprecated KXmlGui RESTORE() macro
• Bump min required Qt/KF to 5.15.2/5.100.0
• Port away from deprecated QLayout::setMargin()
• Add missing includes for Qt6 build
• Remove unused include
• Drop usage of outdated no-effect QGraphicsView::DontClipPainter
• Port away from deprecated QStyle::PM_DefaultLayoutSpacing
• change QFontMetrics.width with horizontalAdvance
• replace QRegExp by QRegularExpression
• Use for instead of foreach
• Replace deprecated endl with Qt variant
• remove -qt5 suffix
• change path in gitlab-ci
• snapcraft: initial import snapcraft files.
• kgrapheditor: deploy ui.rc file as Qt resource
• Remove Designer's "." normaloff file data from icon properties in .ui files
• Add explicit moc includes to sources for moc-covered headers
• doc: use a non-deprecated entity for Frameworks
• Add releases
• Add Open Age Content Rating
• Remove warning about unknown DOT fonts
• Remove custom action to configure shortcuts
• Init graph members
• Remove unused graphviz/gvc.h includes
• Add KI18n and KDocTools macro to install translations
• Port away from deprecated KMessageBox Yes/No API
• Remove arcconfig
• Add interface library for part include dir
• Handle Qt6 change around enterEvent
• Add missing include
• Remove unused include
• Port away from deprecated KPluginLoader
• Port away from deprecated endl
• Adapt build system to Qt6
• Remove pointless/broken icons
• Enable highdpi pixmaps
• Add git blame ignore file
• Add GitLab CI
• Use ecm_qt_install_logging_categories to generate kdebugsettings file
• Drop code variants for no longer supported Qt/KF versions
• Use more target-centric cmake code
• Update .gitignore
• Use non-deprecated KDEInstallDirs variables
• Port away from deprecated KSelectAction::triggered(QString)
• Documentation updates - Update date and fix version numbers - Fix tagging and sync option's text
• Port away from deprecated QMatrix
• KAboutData::setupCommandLine() already adds help & version options
• kgraphviewer_part.desktop: remove unused key Categories
• Use .in suffix for header file that is passed to configure_file()
• Port away from deprecated signal QProcess::error
• Use default window flags for QInputDialog::getText
• Port away from deprecated KEditToolBar::newToolbarConfig
• Port to new KPluginMetaData-based KParts API
• Deploy ui.rc files as Qt resources
• Remove broken argument SERVICE_TYPES kpart.desktop from desktop2json call
• Handle Graphviz capitalization changes
• Capitalize Graphviz consistently
• cmake: Simplify and improve FindGraphviz.cmake
• Add KDE ClangFormat on CMake and run the target
• Fix link: ui.html -> menus.html
• Draw empty arrowheads closed
• add genericname for use on kde.org/applications
• Set StartupWMClass in desktop file
• Use more https in links (and update outdated ones)

Massif Visualizer 0.8.0 has been just released! The main focus of this release is the port to Qt6 and KDE Frameworks 6 as well as general code modernisation, but of course some bugs have been squashed too. The full changelog can be found below.

About Massif Visualizer:

Massif Visualizer is a tool that - who'd guess that - visualizes massif data. You run your application in Valgrind with --tool=massif and then open the generated file in the visualizer. Gzip or Bzip2 compressed massif files can also be opened transparently.

You can learn more at https://apps.kde.org/massif-visualizer/

URL: https://download.kde.org/stable/massif-visualizer/0.8.0/src/
SHA256: 5fad3f0e0d9fbb6bc8cfb744cb4e2c99f231d57ee0dd66dd594d36c2cc588a80
Signed by: D81C 0CB3 8EB7 25EF 6691 C385 BB46 3350 D6EF 31EF Heiko Becker heiko.becker@kde.org
https://invent.kde.org/sysadmin/release-keyring/-/raw/master/keys/heikobecker@key1.asc

Full changelog:

• appdata: Add upcoming 0.8.0 release
• Unbreak KDE CI config: require "@stable-kf6" branch of kgraphviewer
• KDE CI: require tests to pass (for platforms where they currently do)
• KDE CI config: require "@same" branch of kgraphviewer
• appstream: use new id without hyphen
• Port away from QScopedPointer
• ParseWorker: fix switched error title & text for empty data file
• Overhaul action & title texts to follow KDE HIG, add more UI marker contexts
• Config dialog: align "Shorten Templates" checkbox with form fields
• Config dialog: avoid full-width comboboxes, use system style
• Update outdated Kate editor setting replace-trailing-space-save
• Use more function-pointer-based Qt signal/slot connections
• Remove some unused includes
• Use KStandardAction (member-)function-pointer-based overloads
• Use ECM-requirement-derived default KDE_COMPILERSETTINGS_LEVEL
• Drop any margins around document & tool views
• Use QList directly instead of Qt6-times alias QVector
• Switch from target_link_libraries' legacy LINK_PRIVATE to PRIVATE
• Use more target-centric cmake code
• CMake: remove unneeded explicit addition of current dirs to include dirs
• Fix build with older cmake: -D not expected with COMPILE_DEFINITIONS
• Update homepage to apps.kde.org
• Use commits.kde.org/kgraphviewer as source location for KGraphViewerPart
• Set version to 0.8.0
• Use CMake's project(VERSION)
• Drop support for Qt5/KF5
• Support Qt6/KF6 builds
• Rely on CMake's autorcc (enabled by KDECMakeSettings) to add Qt resources
• Use ECMDeprecationSettings
• Use KF6-proof KConfigGroup::group() overload
• Port away from deprecated KPluginFactory::create() overload
• Port away from deprecated KPluginLoader::factory()
• Port away from deprecated KFilterDev
• Port away from deprecated QPrinter::pageRect()
• Port away from deprecated QDesktopWidget
• Port away from deprecated QString::split overload
• Port away from deprecated QPixmap::grabWidget
• Port away from deprecated QTreeView::sortByColumn overload
• Port away from ModelTest copy to QAbstractItemModelTester
• Adapt iterator type to match actual type returned from QHash method
• Add explicit QRegExp includes
• Port away from deprecated QAlgorithmsPrivate::qReverse
• Port away from deprecated qSort
• Bump min required CMake/Qt/ECM/KF to 3.16/5.15.2/5.100/5.100
• appstream: use https for screenshot links
• appstream: use desktop-application type, add developer & launchable tags
• Appdata: Add developer name
• [CI/CD] Add flatpak job
• [CI] Don't depend on kgraphviewer on Windows
• Port to new CI template syntax
• snapcraft: initial import snapcraft files.
• Deploy ui.rc files as Qt resource
• Move Flatpak CI to GitLab
• Add explicit moc includes to sources for moc-covered headers
• Use non-deprecated KDEInstallDirs variables
• Install translations
• Port away from deprecated KMessageBox::sorry
• Remove arcconfig
• Remove unused include
• Use imported target for KGraphViewerPart
• debug
• Add Gitlab CI
• Remove unused XmlPatterns
• Add some missing linkages
• Use KDE_INSTALL_MIMEDIR instead of custom XDG_MIME_INSTALL_DIR
• appdata.xml: Minor fixes for submission to Flathub
• Fix minor issues found by EBN
• fix xml
• update screenshot
• Set StartupWMClass in desktop file
• ui.rc files: use <gui> instead of deprecated <kpartgui>
• Do not duplicate work done by KAboutData::setupCommandLine()
• Use nullptr
• Use override
• Fix window icon for non-desktopfile WM to own icon "massif-visualizer"
• Properly support BUILD_TESTING
• Remove explicit enable_testing(), duplicated from KDECMakeSettings
• Bump min cmake version to 3.0
• Remove explicit use of ECM_KDE_MODULE_DIR, is part of ECM_MODULE_PATH
• Fix minor EBN issues