https://bugs.kde.org/show_bug.cgi?id=503582
--- Comment #15 from [email protected] --- 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. -- You are receiving this mail because: You are watching all bug changes.
