Can reproduce.

*** Bug 488197 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3023

Git commit bf2cfe5f31c2837966178fb951c3f5cb1d824501 by Christoph Wolk.
Committed on 27/05/2025 at 18:32.
Pushed by cwo into branch 'master'.

applets/kicker: fix Plasma.dialog being inappropriately resized

Kicker reuses the current level's cascading popup when a new one is
opened, rather than creatinga completely new one. This usually works out
but fails if the submenu itself has a submenu - the submenu gets resized
correctly, but afterwards is resized again to its previous size. The
specific cause seems to be the subsubmenu hiding itself, if we instead
wait until it is destroyed on the next event loop clear, the resizing
doesn't happen.

So let's not hide it. This seems to be fast enough even on old computers
to not lead to  perceptible lingering subsubmenus, and even if it did
happen in some rare situations, this would seem preferable to having a
menu that's the wrong size long-term.

M  +0    -1    applets/kicker/package/contents/ui/ItemListDialog.qml

https://invent.kde.org/plasma/plasma-desktop/-/commit/bf2cfe5f31c2837966178fb951c3f5cb1d824501

Git commit 01f8cbbbc111d67e709ec9616cdb158d60e245b0 by Christoph Wolk.
Committed on 27/05/2025 at 19:34.
Pushed by cwo into branch 'Plasma/6.4'.

applets/kicker: fix Plasma.dialog being inappropriately resized

Kicker reuses the current level's cascading popup when a new one is
opened, rather than creatinga completely new one. This usually works out
but fails if the submenu itself has a submenu - the submenu gets resized
correctly, but afterwards is resized again to its previous size. The
specific cause seems to be the subsubmenu hiding itself, if we instead
wait until it is destroyed on the next event loop clear, the resizing
doesn't happen.

So let's not hide it. This seems to be fast enough even on old computers
to not lead to  perceptible lingering subsubmenus, and even if it did
happen in some rare situations, this would seem preferable to having a
menu that's the wrong size long-term.


(cherry picked from commit bf2cfe5f31c2837966178fb951c3f5cb1d824501)

Co-authored-by: Christoph Wolk <cwo.kde@posteo.net>

M  +0    -1    applets/kicker/package/contents/ui/ItemListDialog.qml

https://invent.kde.org/plasma/plasma-desktop/-/commit/01f8cbbbc111d67e709ec9616cdb158d60e245b0

This bug still exists and is reproducible on current release version. There is a timing dependence and possibly the previous attempt at a fix made it less likely to occur under ideal circumstances, but when thermal throttling kicks in and CPU runs at a few hundred MHz then it becomes very apparent the underlying issue is NOT fixed.

Please try again in Plasma 6.6 once that is out - I could in edge cases still reproduce it after that patch, but I can't reproduce it anymore after intense reworking of the popup sizing that have already landed in the dev branch of 6.6.

Created attachment 192140 [details]
demo of lethargic menu and remaining reproducible in with the slow-mo menu

I'm not sure the "fix" was worth it. This is only seems fixed in that it is no longer possible to move through menu items quickly. Instead of taking some fraction of a second to settle, it now takes several seconds to show the menu at all. I tried 6.6.0 and hoped the slowness was some fresh bug but it's been in all 6.6.x releases I've tried on t brief forays back in Plasma. At 6.6.4 it remains unbearably slow. Additionally there is still a problem with persistence of certain aspects, not the size but the presence of submenus. When going from a categories with sublevels to the Power menu, the top entries in the Power menu that were sublevels in the previous menu are missing or unusable. I have made a video demonstrating both the intolerably slow response and the Power menu problems. I literally cannot tell if the previous problems reported were in any way fixed or are merely impossible to trigger now.

Please open new bug reports to report new bugs. Thanks!

(In reply to bugs.kde.org from comment #8)
> I'm not sure the "fix" was worth it. This is only seems fixed in that it is
> no longer possible to move through menu items quickly. Instead of taking
> some fraction of a second to settle, it now takes several seconds to show
> the menu at all. I tried 6.6.0 and hoped the slowness was some fresh bug but
> it's been in all 6.6.x releases I've tried on t brief forays back in Plasma.
> At 6.6.4 it remains unbearably slow. Additionally there is still a problem
> with persistence of certain aspects, not the size but the presence of
> submenus. When going from a categories with sublevels to the Power menu, the
> top entries in the Power menu that were sublevels in the previous menu are
> missing or unusable. I have made a video demonstrating both the intolerably
> slow response and the Power menu problems. I literally cannot tell if the
> previous problems reported were in any way fixed or are merely impossible to
> trigger now.

It shouldn't be this slow, and I can't reproduce these issues.

Can you try a new user with default settings so we can rule out some other customization causing a problem?

Is this with software rendering?

I can reproduce the power menu erroneously gaining submenus when you move there from something with submenus; we've caught a couple of these in the past but not this one yet. Easy fix, hope to make it into 6.6.5 still.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6566

I'm glad to hear it was an easy fix. Another little issue I've noticed is the width is rarely sufficient to show the application names and descriptions without cutting off parts. I'm not sure when this started, if it was at 6.0 or some later version. The other issues were more distracting so it may have taken a while to notice. It doesn't seem to be an issue of hitting a hard maximum width, the width of each submenu is different so there must be some attempt to calculate an appropriate width but somehow the result is never sufficient to not truncate the descriptions. Sometimes it starts off re-using the width of the previously displayed submenu and then after a second or two pops out to a greater width, but still not wide enough.

As to the performance, it has always been the case than anything using QML  is noticeably slow and stuttery compared to native QtWidgets, but something changed with 6.6 where it became much worse. This is not with software rendering, it's running on the Intel iGPU which is hardly any faster than software render and much more buggy. This laptop has a decent radeon dGPU which works well for games, but try as I might it seems impossible to use that for desktop compositing; kwin gets stuck in a crash loop if I try to force it onto the dGPU. For a long time I had to use xrender compositing because there was rampant screen corruption, freezing of portions of the screen, and effect animations got stuck looping after they should have ended if I let kwin use OpenGL for compositing. When the option for xrender compositing was removed, I had no choice but to use OpenBox as window manager and picom as xrender compositor. After more than 5 years, the Intel drivers finally got to a point where the only one of those issues that remains is the sticking effects, so I can finally use kwin again with only minor annoyance.

I had been alternating between LXQt and KDE, but the past half year I've been using LXQt almost exclusively as my DE with kwin_x11 as WM and compositor, because the situation with Plasma has been deteriorating so severely over the last few versions. Each new point release I give Plasma another shot, but each time I find more issues rather than improvement and so the time I spend in it before going back to LXQt decreases each time. With the release of 6.6 I didn't know if I should laugh or cry; it's become hilariously bad. At least this has pushed me to fix some of the rough edges in LXQt, so I don't really miss Plasma as much, and I was going to have to give it up soon enough anyway due to the impending removal of X11 support midway through the lifespan of KDE6.

> It doesn't seem to be an issue of hitting a hard maximum width, the width of each submenu is different so there must be some attempt to calculate an appropriate width but somehow the result is never sufficient to not truncate the descriptions. Sometimes it starts off re-using the width of the previously displayed submenu and then after a second or two pops out to a greater width, but still not wide enough.

Obviously something makes the resizing really slow on your computer.

There is a default size, and it can grow up to 1.5 times that size.

(In search results, it's fixed to 1.25 times that size, rather than growing, as having this dynamic caused inherent visual issues as columns appear and disappear and resize at the same time).

6.7 will have tooltips if you need to see the elided parts. Given how unreasonably long the Comment lines for some apps can be, always making it large enough to show it fully would not be a good idea - some people would get stuck with a submenu that covers the whole screen.

> This is not with software rendering, it's running on the Intel iGPU which is hardly any faster than software render and much more buggy. 

I'm developing this on a 10-year old laptop with an Intel iGPU (and no dGPU), and it's completely snappy.

I've also had no other reports of this kind of slowdown.

X11 may be related; I have tested things occasionally (on a different computer with more powerful hardware) and didn't notice anything out of the ordinary, but effort and testing there are very limited. So possibly a combination of that and something with your specific setup.

I would be fine with having it as wide as the screen if that's what it takes to fit the content. When I'm interacting with the kicker menu, it is the top-most layer and there is no reason to see anything below. I expected there was some max width enforced, which is why I specifically point out some of submenus are less than that width and cutting off even more text than necessary. I would also prefer a multi-column view rather than the scrolling for menus that contain too many items to fit in a single column constrained to the height of the screen, which is reduced relative to total area as screens get wider. It is far faster to find and select the desired item when I can see them all at once instead of having to fiddle about scrolling a menu. This is another benefit of LXQt, it shows everything at once and almost immediately upon activation.

Indeed something makes resizing slow like any other drawing. The sensible approach would be to determine contents and size before starting to draw anything so that the menu can be created with the correct dimensions rather than going through this game of creating things wrongly sized/positioned and then making corrections, which of course leads to everything drawing in multiple steps during which everything is visibly broken. Not only would it look better, it would most likely be much faster since he drawing via QML is much more time consuming than enumerating contents and calculating the required dimensions. It would also help if menus did not appear until clicked on, and remained expanded even if the cursor leaves their bounds, unless I am holding down the mouse button in which case the live tracking of the cursor would explicitly desired, as has been the common convention for decades, but a convention which Kicker now ignores. Part of the promise of a composited desktop was not seeing programs in intermediate steps of drawing, window contents being visibly repainted. That was achieved, then demolished with the transition from native widgets to QML, leaving us now in a state worse than where we started. The old way of live painting was faster and less janky with or without any amount of rendering assistance from the video hardware.

Wayland sessions have always been unbearable, multiple seconds of lag for anything on screen and bugs galore. I never intend to start a Wayland session, but periodically some trick is pulled and the session in SDDM is changed to something other than the last used, which is not immediately obvious; I should not need to open the session list to make sure something hasn't changed it behind my back. The last time I ended up in a Wayland session by accident, it was immediately obvious because not only was the UI barely responsive but the kicker menu opened a couple inches above the panel and I soon figured out that the lower ~20% of the screen was dead space; no window could be resized or moved into it as if the screen just ended there, except the panel down at the bottom. Frankly, I'm scared to even try Wayland sessions because I previous unintentional foray into one wrecked havoc on kwallet. Some of the contents of kwallet were moved into other folders or simply gone! All chromium-based browsers and electron apps were affected. Through some back and forth between X11 and Wayland sessions I was able to catch the appearance of a new key in kwallet, and since the chromium keys were still present, just in the wrong place, I could copy the content of the pair of keys to the other location so browsers could decrypt the user profile again. Signal Messenger, an electron app, on the other hand would have been a loss had I not previously had to decrypt it's storage key and stored that safely in a text file. So I was able to re-insert that into it's config file as plaintext, so it could then store than into kwallet and replace it with the obfuscated version on the next start.

The cynic might say that the sudden severe slowdown of QML might be intentional in order to handicap it to be no better than the Wayland experience in an effort to try to convince everyone getting forced to Wayland that it is an improvement, or at least not a regression. Wayland is still worse because even the applications using native widgets feel lethargic; they are probably fast to respond but there is a significant delay before the result is presented on screen. The Wayland slowdown is not only experienced by me; a friend mentioned that he immediately knows when he is in a Wayland session because the text rendering is visibly poor and the entire GUI has 1-2 seconds of lag. We use different Linux distributions on different hardware, his workstation has a Radeon card with several time the capability of the my laptop's dGPU (which cannot be used for Plasma/kwin) and yet it is similarly slow, so this is a universal issue.

To give the benefit of the doubt, it may indeed be that the degradation is accidental and went unnoticed if all the KDE developers are solely focused on Wayland and not routinely testing X11. Unfortunately, that reinforces the perception of a disconnect between their agenda and what the users desire. We thought we had until the end of KDE6 to make use of what was left of KDE now that it's past its peak, during which we could find an alternative or devise a plan to keep a X11 version alive. However, we have gotten news several times now that the end is nearer than thought, support for X11 is being removed a piece at a time mid-lifespan, thus leaving us far less time to make and execute an escape plan. Most distros will simply update packages to the new versions without making the effort to preserve a separate set of X11 compatible packages for KDE components that become Wayland only, and most users are stuck to using what their distro of choice provides because they do not know how to do otherwise nor that there is even an option to do otherwise. 

I'm part of the small minority that can do something about addressing my own needs, which is why I've been fixing some of the shortcomings in LXQt as I can make time to do so and in the order of priority set by personal need. However, this distraction diverts from other areas I'd prefer to be working on; desktop UI is not my primary interest, but when decades of sensible convention is thrown by the wayside then I have to take a break from other work to address the issue before it gets to a point where I cannot get any work done. It is far less work to polish something like LXQt and make it suitable for my needs than it is to try to reverse KDE's course, where I would be dealing with a much larger code-base, a significant part of which is in newfangled web-tech languages (QML and JS), while paddling upstream against the current.

Git commit 175b6041d69506e0193419a51e3f858696bcc9ea by Christoph Wolk.
Committed on 13/05/2026 at 07:14.
Pushed by cwo into branch 'master'.

applets/kicker: return more roles explicitly

Similar to ef0009ad and 510bd959

Kicker's models sometimes return an empty QVariant if the role is
irrelevant to the model. This breaks with required bool properties if
the ListView is reused with a different model; the empty QVariant does
not become false, but maintains the previous value. Main kicker's
submenus reuse the listview, so moving e.g. from an app category submenu
to Recents or system actions may cause entries there to be
inappropriately marked as subcategories, separators, or (in 6.7) as
newly installed.

Instead, explicitly return bool false for the roles where this may be an
issue.

M  +2    -0    applets/kicker/appsmodel.cpp
M  +12   -0    applets/kicker/recentusagemodel.cpp
M  +8    -0    applets/kicker/systemmodel.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/175b6041d69506e0193419a51e3f858696bcc9ea

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6580

Git commit ec035323820781cc1a1f9af12de4f77bf4431952 by Christoph Wolk.
Committed on 13/05/2026 at 09:36.
Pushed by cwo into branch 'Plasma/6.6'.

applets/kicker: return more roles explicitly

Similar to ef0009ad and 510bd959

Kicker's models sometimes return an empty QVariant if the role is
irrelevant to the model. This breaks with required bool properties if
the ListView is reused with a different model; the empty QVariant does
not become false, but maintains the previous value. Main kicker's
submenus reuse the listview, so moving e.g. from an app category submenu
to Recents or system actions may cause entries there to be
inappropriately marked as subcategories, separators, or (in 6.7) as
newly installed.

Instead, explicitly return bool false for the roles where this may be an
issue.


(cherry picked from commit 175b6041d69506e0193419a51e3f858696bcc9ea)

Co-authored-by: Christoph Wolk <cwo.kde@posteo.net>

M  +2    -0    applets/kicker/appsmodel.cpp
M  +12   -0    applets/kicker/recentusagemodel.cpp
M  +8    -0    applets/kicker/systemmodel.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/ec035323820781cc1a1f9af12de4f77bf4431952