This week in KDE: Looking towards Plasma 6.1

Automation & Systematization, This Week in KDE 5 Minutes

This week we put some of the final Plasma 6.0 bugs to rest, and continued working towards Plasma 6.1 with a variety of UI improvements. Nothing ground-breaking this week, just a slow grind of useful work towards a solid release!

UI Improvements

Kate now considers a file as recent when it’s saved or closed, not just when it’s opened. This means your recent files list will no longer omit files you kept open for a long time while working on them (Christoph Cullmann, Kate 24.05. Link)

The panel icons for Kickoff (Application Launcher) and Kicker (Application Menu) widgets are now capped in size so they can’t grow ridiculously huge on thicccc panel (Akseli Lahtinen and me: Nate Graham, Plasma 6.0.5. Link 1 and link 2)

System Settings no longer lets you choose GNOME’s Adwaita or High Contrast icon themes as your systemwide icon theme, because despite registering themselves as FreeDesktop-compatible icon themes, they are no longer actually designed to be used this way and will break everything from KDE if you try anyway (me: Nate Graham, Plasma 6.0.5. Link)

The screen that KWin considers active for the purpose of determining which screen to open new windows on is now determined by “last user interaction”, which includes things like mouse movement and keyboard focus. Hopefully this should better match people’s expectations (Xaver Hugl, Plasma 6.1. Link)

Made the wallpaper chooser views frameless, matching the current styling of most other settings pages in System Settings and Plasma (me: Nate Graham, Plasma 6.1. Link 1 and link 2):

Plasma’s notifications now use a more appropriate icon for canceling jobs, and also elide long title text in the middle rather than on the left (Ivan Tkachenko, Plasma 6.1. Link 1 and link 2):

Ok, so maybe “plasma-brows…gration-host” is not a work of towering genius. The fact that a long ugly technical name is shown there is another bug we’ll investigate.

Refined the UI shown when changing global themes to make it clear what will happen and what’s potentially dangerous (me: Nate Graham, Plasma 6.1. Link 1 and link 2):

When you use the command-line powerprofilesctl tool to change power profiles, the new state is now reflected in the Power and Battery widget (Natalie Clarius, Plasma 6.1. Link)

Several Breeze icons (folder-encrypted, folder-decrypted, and folder-music) now have proper symbolic versions at their 16px and 22px sizes (me: Nate Graham, Frameworks 6.2. Link)

Bug Fixes

Gwenview no longer fails to open large images; now its Qt 6 version can open the same size of image that the Qt 5 version could (Méven Car, Gwenview 24.05. Link)

On Wayland, KWin no longer crashes when it’s unable to open a socket to XWayland for some reason (Vlad Zahorodnii, Plasma 6.0.5. Link)

Fixed a case where Plasma could crash while modifying the set of favorite apps in Kickoff (Application Launcher), Kicker (Application Menu), or another launcher menu using the same backend infrastructure (Fushan Wen, Plasma 6.0.5. Link)

When using Qt 6.7, the System Tray popup is no longer sometimes inappropriately resized to a tiny nub, and also clicking a System Monitor widget showing GPU sensors no longer causes Plasma to freeze (Marco Martin, Plasma 6.0.5. Link 1 and link 2)

Fixed an extremely strange issue that could be triggered by opening any windows of IntelliJ IDE apps, and would cause other windows and Plasma panels to become transparent to clicks (Vyacheslav Mayorov, Plasma 6.0.5. Link)

When waking the system from sleep, quick-tiled windows no longer sometimes disappear, and vertically-maximized windows are no longer sometimes mis-positioned (Xaver Hugl, Plasma 6.0.5. Link 1 and link 2)

On X11, forcing tablet mode on when using a multi-screen setup with global scaling no longer causes one of the screens to scale everything incorrectly (Xaver Hugl, Plasma 6.0.5 Link)

Applied a workaround in KWin for an AMD GPU driver bug, which should reduce instances of random visual glitchiness (Xaver Hugl, Plasma 6.1. Link)

Fixed another case of Korners™, this time for menus in QtWidgets-based apps (Ivan Tkachenko, Plasma 6.1. Link)

Resizing a window with a wallpaper chooser grid in it no longer sometimes causes the grid view’s header to disturbingly detach and appear in the middle of the view (me: Nate Graham, Plasma 6.1. Link)

More audio and video files now have appropriate icons, and when no suitable format-specific icon is found, the system will no longer fall back to an inappropriate symbolic speaker or filmstrip icon (Kai Uwe Broulik and me: Nate Graham, Frameworks 6.2. Link 1 and link 2)

Fixed a case in Kirigami where some UI elements would have incorrect colors when using mixed light/dark color schemes (Evgeniy Harchenko, Frameworks 6.2. Link)

After we fixed the “Pick your installation option popup” in the “Get new [thing]” windows, Qt 6.7 broke it again, so we fixed it again! This time moar betterer (Akseli Lahtinen and Ivan Tkachenko, Frameworks 6.3. Link)

Fixed an issue that caused apps with System Tray icons to inappropriately quit when deleting their tray icons (Tor Arne, Qt 6.7.2. Link)

Other bug information of note:

Performance & Technical

Implemented a bunch of security hardening for our crash reporting system based on feedback from SUSE’s security team (Harald Sitter, Plasma 6.0.5. Link)

Automation & Systematization

Added multiple autotests to ensure that mounting different types of mountable filesystems works as intended (Stefan Brüns, Frameworks 6.2. Link)

Added an autotest to make sure that Plasma-themes UI elements that should have the same height—such as text fields and buttons—still do even if the Plasma style is changed (Fushan Wen, Plasma 6.1. Link)

…And Everything Else

This blog only covers the tip of the iceberg! If you’re hungry for more, check out https://planet.kde.org, where you can find more news from other KDE contributors.

How You Can Help

The KDE organization has become important in the world, and your time and labor have helped to bring it there! But as we grow, it’s going to be equally important that this stream of labor be made sustainable, which primarily means paying for it. Right now the vast majority of KDE runs on labor not paid for by KDE e.V. (the nonprofit foundation behind KDE, of which I am a board member), and that’s a problem. We’ve taken steps to change this with paid technical contractors—but those steps are small due to growing but still limited financial resources. If you’d like to help change that, consider donating today!

Otherwise, visit https://community.kde.org/Get_Involved to discover other ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Published by Nate

Published

38 thoughts on “This week in KDE: Looking towards Plasma 6.1”

  1. The exchanges with the maintainer on that adwaita-icon-theme issue are painful to read. I commend your ability to keep a completely neutral and diplomatic tone throughout. I’m not sure I could have managed.

    Liked by 2 people

    Reply

    1. Yeah, I wanted to say the same. But while the start of the discussion was hard to read, it eventually got constructive. Hats off to you, Nate, and all parties involved.

      Liked by 2 people

    2. The “interpretation” reply screamed “asshole”. I would have lost it. Made me relive every failed discussion I’ve ever had with gnome devs over the decades and why I don’t use gnome anymore. And why I fund KDE.

      Like

    3. Nate has the patience of a saint dealing with those folks.

      Although, I recall something similar (albeit not nearly as heated) from the KDE side also: https://bugs.kde.org/show_bug.cgi?id=444249 – expecting the application to cater for flaws in the default theme.

      But I digress. This entire icon theme mess can be resolved if the Linux/FDO devises a standardized resource section to embed inside executables and shared libraries like Windows EXEs and DLLs have, which embeds icon(s), version information and other data inside it. Desktop environments, file managers and other tools can query this information directly from the executable or shared library in question.
      Qt partially recognises the need for this by allowing icons and glyphs to be embedded into the executable, which can be used by widgets, but it’s not the same as being able to be queried externally in a standardized manner.

      There are even DLLs which only have a stub of executable code that does nothing, whose sole purpose is to have a resource section containing icons and glyphs for various appliacations. Linux packages and icon themes could do the same with its executables and shared object libraries if there was a standardized resource format.

      This would solve all the issues of icon themes trying to include every icon for every rinky-dink application, many of which nobody would have installed on their system. This would result in much less bloat.
      Icon not present in an icon theme? Use the one inside the executable!

      Liked by 1 person

    3. 100 to 200 bugs being fixed per week.

      Have you ensured there are bug reports for all the issues you’re seeing and added any additional information you can? Have you tried to escalate any of these to 15 minute bugs if they fit the bill?

      Like

    4. Yes I do. And they aren’t 15 minutes bugs, they are 5 minutes bug. Anyway, nobody cares at all. It’s the pouring new things with this team, not fixing bugs. It’s nearly unusable.

      Like

    5. Amusingly enough, this week doesn’t mention any new features, so we literally did concentrate on bug-fixing rather than new features. 🙂

      Liked by 1 person

    7. I mean, he is not wrong. being dissatisfied and voicing an opinion you don’t agree with isn’t trolling.

      There is a lot of very old standing standing bug that just get ignored (some for actual reasons – like not being relevant, some because… they just are, no reason). the filepicker bug meme, a nearly 20 year old bug, was a thing for a reason (and it still is, technically, you need to manually edit the firefox shortcut to not use the ugly filepicker from the 90s).

      the 15 minute bug initiative is good, but there should be a 5 minute bug initiative as well. some things are glaring.

      that said, some bugs are also being worked on so he’s not being fully honest either.

      Like

  5. Hey Nate,

    a suggestion regarding this blog:

    • put it under blogs.kde.org
    • generated as SSG via something like GoHugo from KDE gitlab (instead of wordpress)?
    • for every post generate a thread under discuss.kde.org/blogs/<user>/

    Like

    Reply

  6. Nate “Ice Man” Graham. 😎

    Very professional interaction with the Gnome team from your side; can’t say the same regarding some of their number.

    Unfortunately I suspect it’s going to become increasingly difficult to maintain interoperability with GTK apps and any other artefacts of Gnome development, which is a loss for the community.

    Liked by 1 person

    Reply

    1. Thanks, I appreciate it. Indeed, working together has been challenging unfortunately. The remaining areas of active collaboration are Wayland protocols and Portals development, and it’s quite common for the different cultural perspectives and development philosophies to clash. It really takes work from those with patience and cool heads to try to steer discussions in productive directions.

      Liked by 1 person

  7. I noticed context menus spawn on the wrong screen when using X11 (haven’t tested Wayland). In my case I have dual screen setup (left mirror with another screen and right a single screen). When opening a context menu on the right screen they spawn on the left screen.

    So far this only seems to affect Qt apps. Is it a Qt bug then?

    Like

    Reply

  9. I really felt your frustration with those gnoomy folks, they are obsessed with their Adwaita and LibAdwaita things, they think their apps are superior and more modern than others. They really deserve all hates from non GNOME users.

    Liked by 1 person

    Reply

    1. “hate” brings no one closer and does not help anyone. It’s never a solution or even an ansatz. Nate’s reaction were the right way: Simply get into talk, while keep being nice and try to work things out together! 🙂

      Liked by 1 person

    2. Personally, I truthfully hate them and their weird ideas, they banned my two accounts on their gitlab simply because I criticized their loved Adwaita, they will never reach the level of KDE community. They attempt to lock and isolate any ported GTK4 to look good only on GNOME by promoting LibAdwaita as the official GTK4 framework.

      Liked by 1 person

  10. Hi Nate!

    I just wanted to say thank you. You always blow me away with the work you do trying make positive change with the unhelpful gnome devs. I read through the issues you made over at a-i-t and xdg-specs to try to make icons work better for everyone, and I don’t know why they were so disrespectful to you, but your politeness when faced with their bickering and commitment to fixing these systemic problems in the face of such absurd gnome-infested backlash was awe-inspiring.

    Thanks for everything you do for us!

    Liked by 1 person

    Reply

    1. Thanks for the kind words!

      If I had to speculate, I think a lot of GNOME people unfortunately operate under a siege mentality: they get so much criticism that they’re primed to defend themselves and their project 100% of the time. So even when the feedback is reasonable and phrased reasonably, they just have that same reaction and have to be talked down from the edge of the cliff, so to speak.

      Not all GNOME people are like this, but enough are (including some of the most prolific ones) that it’s a thing people run into constantly.

      Personally I think a lot of the criticism the GNOME folks get is unfair; it’s their project, they get to do what they like with it. And there’s plenty of choice out there for people who don’t agree with their decisions. Now, in cases like this where they’re withdrawing from a shared standard, I find it disappointing, but still, it’s their right to do so—as long as they withdraw correctly, which was the problem here! There still seem to be lots of other participants who appreciate the icon specs.

      And paradoxically, I think the GNOME folks did the exact opposite of what they should have: they should have broken compatibility with the icon theme spec, but *not* the icon name spec, rather than the reverse. That way their Adwaita icon theme would become an internal-only thing that GNOME apps use, reduced to a convenient bucket of GNOME app icons stored in a central location.

      This is what the Breeze icon theme is: a convenient place to hold icons for all KDE apps, so they don’t have to bundle them internally. It also happens to conform to the icon theme spec so users can override it if they want, but its primary purpose is as a central repository of icons.

      Liked by 1 person

    2. While I mostly agree with Nate, I’d like to point out that KDE is not doing it right, either. If the user selects another icon theme (e.g. Oxygen), Plasma should automatically fallback to Breeze for those KDE-specific icons, and there is code that tries to do that, but it doesn’t work. So using any icon theme that doesn’t explicitly inherit Breeze would leave a lot of broken icons in Plasma.

      Like

    3. It’s true. I won’t pretend that the FDO icon theme specs or our implementation of them are perfect. They clearly have significant conceptual and implementation issues.

      Chrostoph has done an amazing job of working out the kinks of our icon loader implementation over the past week though. So good things are happening!

      Like

  11. I’m so looking forward to 6.0.5 at this point.

    The transparent window interaction bug was driving me crazy on IntelliJ IDEA, I’m super grateful someone took the time to report it and someone else to fix it!

    Being probably the single most used app on my workstation of FF and Teams, it’ll really be a major quality of life improvement!

    If you are reading and also use Jetbrains IDEs on a regular basis, also be aware that you can test native Wayland builds, which are not yet good enough for daily use for me, but are getting closer after each passing week.

    More info here:

    https://blog.jetbrains.com/platform/2023/08/wayland-support/#remark42__comment-a864d43f-6aa9-4412-8e11-833673331792

    Liked by 1 person

    Reply

  13. “….also elide long title text in the middle rather than on the left.”

    Um. I’d rather it was on the right. And could a mouseover create a popup with the full name in it?

    Like

    Reply

  14. Applying a desktop layout will delete the current set of desktops, panels, docks, and widgets, replacing them with what the theme specifies.

    global theme warning

    Any operation that dangerous cries out for an undo button. 

    I know that I personally would never click Apply after having seen that, since it took me an hour or so to get my panels set up right, with 2-row taskbar, pinned items, Memory & Zram usage widget, CPU usage widget with visually distinct colors, Windows 7-style “show desktop” widget from Pling, etc. I don’t know if I even could reproduce it from memory.

    Liked by 1 person

    Reply

  15. Please, bring sddm and rounded corners into plasma 6.1.

    https://invent.kde.org/plasma/kwin/-/issues/198 and https://invent.kde.org/plasma/plasma-desktop/-/issues/91

    Also, I know it was already mentioned here, but having a context menu in the dolphin file manager for formating USB drivers is something I really miss when I switched from Windows to plasma. Please consider this feature into newer plasma versions, I’m sure many will like it. Thanks

    https://bugs.kde.org/show_bug.cgi?id=377253

    Liked by 1 person

    Reply

  16. I see the discussion about interoperability of icon themes has moved to “Making FDO icon theming useful for app developers again”. There one of the GNOME people says they are “more interested in internal consistency—the ability of their application to run exactly as they developed and tested it—than external consistency.” So now i actually understand on why they don’t want to support (icon) themes in general and on why GNOME apps look so misplaced, when used outside GNOME. They want to make GNOME (apps) as rigid and non customizable as possible. As imagine if developer uses some icon on the button and then an image on the web emerges, on where the end user changed the icon theme and the icon is now different. That is just horrible and the end of the world is nearing. So why are GNOME people then even refuting all proposals for possibly improving the icon theme specification, on where it makes sense, as good luck on inventing and agreeing on the new and different one, if their ultimate goal is to not allow for any customization at all and in the first place? Their arguments against proposals are then actually serving a different purpose of sabotaging progress. And what to do about it in general, on where such prominent FOSS project goes sour? Hopefully, for starters, some fork of Libadwaita to emerge, that would allow more external consistency. For a GNOME app to again look good when used in KDE? Would GNOME devs be able to handle it? This last part obviously is a joke and i guess we need to accept the new reality. People and distributions to make choices, on what they personally support and i can only hope that the dark ages GNOME is trying to impose on the Linux world won’t prevail and the good will win. Icon themes are good.

    Liked by 1 person

    Reply

    1. Nowadays, most new apps are in Electron, not GNOME. And each of these apps (e.g. vscode, browsers, Electron-based terminal emulators) has its own theming system and icon themes, which KDE can do nothing about.

      So yes, as you said, we need to accept the new reality. Apps just won’t have a uniform look. FDO still works for KDE and plenty of other DEs, but I doubt there’s much benefit persuading GNOME developers, because as I said above, GNOME apps aren’t that important, Electron is. And there’s nothing you can do with Electron.

      Liked by 1 person

  17. It’s amazing how stable and good Plasma 6.0 feels (and in many different hardware/setups), and it’s just the first release! I can’t wait to test the 6.1 Beta 🙂

    Liked by 1 person

    Reply

Leave a comment