On X11 there is a really cool feature that allows users to make a window disappear and keep only its title bar visible. It is accomplished by hovering the title bar and scrolling up with the mouse (scroll down to make the window visible again). On Wayland, I can achieve it only with XWayland windows.
Created attachment 104346 [details] attachment-24320-0.html Window shading is currently only implemented for X11 windows.
Btw. even when implemented we will only be able to offer it for Qt applications as GTK uses client side decorations. Overall I want to implement shading just to reduce the differences, but it does not have a high priority as shading is nowadays a hardly used feature.
Still not working. Operating System: Arch Linux KDE Plasma Version: 5.17.90 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.1
Window shading now seems to be working for non-Qt apps. Doesn't work for kde /qt apps. Operating System: KDE neon 5.22 KDE Plasma Version: 5.22.3 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.3 Kernel Version: 5.8.0-59-generic (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: Radeon RX 580 Series
*** Bug 443481 has been marked as a duplicate of this bug. ***
(In reply to Zamundaaa from comment #5) > *** Bug 443481 has been marked as a duplicate of this bug. *** Thank you. This feature, historically unique to KDE since many years, really deserves to be known and thus implemented for Wayland ? And so much powerful when combined with always on top!.. Is it that hard to develop since 2017 ?
There's a WIP for it: https://invent.kde.org/plasma/kwin/-/merge_requests/1183
(In reply to Zamundaaa from comment #7) > There's a WIP for it: > https://invent.kde.org/plasma/kwin/-/merge_requests/1183 Thank you so much !
*** Bug 445640 has been marked as a duplicate of this bug. ***
Can confirm. Seems that the MR was closed. Any other progress related?
*** Bug 459034 has been marked as a duplicate of this bug. ***
Hi. I just read Nate's https://pointieststick.com/2022/12/31/highlights-from-2022/, in which he said "Our list of showstoppers continues to shrink, and new issues added to it are or notably less bad than the ones they replace. ... And if you’re tempted to grumble, “well, Wayland still doesn’t work for me for $REASON,” please do it in a bug report so developers can fix it!". So, i decided to make a bug report for W's lack of window shading, but found this [& other] existing BRs for it. Your Wayland progress has been collectively wonderful [thanks!], such that since 5.25.x i've been able to use it as my daily tool for large swathes of contiguous session-time. Every now & then, though, i retreat to X11 for two main reasons; 1. The ongoing misbehaviour in W of PiP, per https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/44; 2. the tragic ongoing lack of window shading in W, per this current bug report. In the next few hours when i've completed some current stuff, i intend to logout of W & back into X again, as i genuinely miss those very productive features. I'd like to record these: a. afaik this problem has never been included in the Showstoppers at https://community.kde.org/Plasma/Wayland_Showstoppers; certainly at least it's not there now nor for the past year. For MY use-case, it IS a showstopper, & i suspect i'm far from alone. b. Martin, above, said "it does not have a high priority as shading is nowadays a hardly used feature". That statement shocks me, so i wish to strenuously protest it as a counter-opinion. c. Yan, above, said "This feature, historically unique to KDE since many years". I don't think this is correct. Cinnamon & Xfce, at least, most definitely have shading [X11 only, ofc], so Plasma's absence of this in Wayland is a distinct functionality degradation IMO. Please, can we Shaders have any cause for hope in Plasma 5.27.x's or more likely 6.x's Wayland? *** Operating System: Arch Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 5.15.85-1-lts (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-4790 CPU @ 3.60GHz Memory: 30.8 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4600
Adding it to that page seems reasonable as there does seem to be quite a lot of demand for this feature.
Especially, if you really want to convert the long term power users! A not too small share of them make use of this feature. If you get used to it, you will not want to do without it.
The merge request (https://invent.kde.org/plasma/kwin/-/merge_requests/1183) has thankfully since been reopened but hasn't seen much more action in the last 5 months. Going to pop a ping to see if we can reinvigorate the activity.
Hi, if I wanted to take care of this MR - https://invent.kde.org/plasma/kwin/-/merge_requests/1183/diffs - and make sure it gets merged into master, what would I need to do? Communicate to the author if he's still up to resolve the comments? If not, could I do that instead of him? Not sure what the agreed policy on this is, sorry if it's something obvious or well known, I'm just getting into contributing :)
You could re-submit it yourself, addressing comments on the last one. You can always make your case. But there is no guarantee that it will be merged.
I've just read https://pointieststick.com/2023/05/11/plasma-6-better-defaults/. I'm most dismayed to see, afaik, that during this review, the team apparently removed the *only-relatively-recently-added* item for **window shading / rollup**, per https://bugs.kde.org/show_bug.cgi?id=377162#c13 above [which DID briefly then appear thereafter]. Ofc i can understand that some Devs might not have wanted it in the new priority category, but to also then omit it from the secondary category is very saddening. Is this really now the end of the road for it?
We might add it back to the "annoyances" section. Unfortunately the fact remains that it's quite a niche feature that's hard to support properly on Wayland. Nobody's vetoed it, so there's always a chance it will get implemented there, but it will most likely require a DIY effort by someone who really loves it.
*** Bug 473041 has been marked as a duplicate of this bug. ***
*** Bug 474553 has been marked as a duplicate of this bug. ***
Another response to indicate that lack of shading is an impediment to my fully moving to a Wayland based system. This is so ingrained in my daily operation that not having becomes a process stumbling block. Please consider implementing this as soon as possible in light of the future move of major OS's to Wayland.
*** Bug 479381 has been marked as a duplicate of this bug. ***
*** Bug 481279 has been marked as a duplicate of this bug. ***
*** Bug 482220 has been marked as a duplicate of this bug. ***
Following a fresh install of KDE Neon 6.0, I've set up a few panel widgets to run Chrome apps, using the "--app=" argument. These seem to shade correctly. I thought perhaps these were ignoring the Window Behaviour system settings altogether, but if I set the Titlebar Action to "Minimse", rather than "Shade", then they correctly minimise, as do other windows. Very odd.
This is an annoying bug in Wayland - I've just gotten so used to setting mouse wheel to shade/unshade and the upgrade to Plasma6 & Wayland without this means I've lost a major plus feature. Operating System: openSUSE Tumbleweed 20240319 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.1-1-default (64-bit) Graphics Platform: Wayland
(In reply to Alan Prescott from comment #27) > This is an annoying bug in Wayland - I've just gotten so used to setting > mouse wheel to shade/unshade and the upgrade to Plasma6 & Wayland without > this means I've lost a major plus feature. > > Operating System: openSUSE Tumbleweed 20240319 > KDE Plasma Version: 6.0.2 > KDE Frameworks Version: 6.0.0 > Qt Version: 6.6.2 > Kernel Version: 6.8.1-1-default (64-bit) > Graphics Platform: Wayland Aha. I used Mouse Gestures heavily in the past - to manage my windows mostly - as well as occasionally shading a window here and there... Now that we're moving to Wayland, and leaving (at least for now...) the likes of 'Easystroke' and hoping for development on the likes of 'Mouse Actions' then this redundant (visible, but not working) feature is rather a nasty tease.
Just switched to Wayland because Plasma 6 with Fedora 40, and overall it's "just fine". Had been avoiding the X->Wayland upgrade for years, was pleasantly surprised at things overall/ However, I just encountered this bug. If it's to be considered an unimplemented feature rather than a bug, could it be removed from the options in "Settings->Window Management", which still lists "shade" as a thing you can assign to, for example double clicking on the titlebar?
(In reply to Alec Habig from comment #29) > Just switched to Wayland because Plasma 6 with Fedora 40, and overall it's > "just fine". Had been avoiding the X->Wayland upgrade for years, was > pleasantly surprised at things overall/ > > However, I just encountered this bug. If it's to be considered an > unimplemented feature rather than a bug, could it be removed from the > options in "Settings->Window Management", which still lists "shade" as a > thing you can assign to, for example double clicking on the titlebar? As per my various historic posts, i continue to desperately hope the KDE Devs will eventually find a way to bring this VITAL function into their Wayland codebase. I've used Wayland now for a couple of years, but still badly pine for this missing function the same as the first day. On the rare occasions i revert briefly to X11 i always revel in being able to Shade at will.
(In reply to Peter from comment #26) > Following a fresh install of KDE Neon 6.0, I've set up a few panel widgets > to run Chrome apps, using the "--app=" argument. These seem to shade > correctly. I thought perhaps these were ignoring the Window Behaviour > system settings altogether, but if I set the Titlebar Action to "Minimse", > rather than "Shade", then they correctly minimise, as do other windows. > Very odd. Just to add to this, I've recently installed Edge. Now I have Chrome which shades and Edge (installed using Flatpak) which maximises. All other windows, including Octave which the only other application I installed using Flatpak, do nothing.
*** Bug 494078 has been marked as a duplicate of this bug. ***
During Akademy 2024, I attended the KWin BoF and raised this question. While Vlad told me directly implementing shading is impractical for various reasons, I remember there was someone who talked about the idea of "shading as iconify," i.e. displaying shaded window as an "icon" whose content is the title bar, and seemed to imply that it was more practical. There is something similar in the comment of the MR: > Would it simplify things and also be acceptable to deny the user any control of the size of an already shaded window? The shaded window just matches the unshaded width. kitty (which I just confirmed is not running on xwayland) and xwayland progroms seem to be able to shade as well.
Shading into an icon would be acceptable, I think. At least for me.
From my point of view, resizing of shaded windows makes no sense so prohibiting to resize such windows is reasonable way to avoid respective bugs and inconsistencies. Applies to [un]maximizing too. I don't think that I am the only person who has never ever tried to resize a shaded window because there are 0 reasons to do that except for testing and hunting bugs.
Any technique, including simply creating a desktop icon with an appropriate lable, would be an improvement over not allowing you to "set aside" a window without forcing it to the task bar. Using an icon is not optimal, in my opinion, but it would be better than nothing.
Hello there! I also grew to love this feature and I`m on track with Matija, Vladimir and Richard agreeing that the option to shading to an icon would be better than nothing but then again shading to a full titlebar - where you have space for information, like the window title - would be awesome! On my end the only application I run into, that would accept shading is the vivaldi browser (extra/vivaldi 7.0.3495.27-1). Beste Grüße aus Berlin! OS: EndeavourOS x86_64 Kernel: Linux 6.12.4-arch1-1 DE: KDE Plasma 6.2.4 WM: KWin (Wayland) Using Qt version 6.8.1 WM Theme: Klassy
(In reply to Matija Šuklje from comment #34) > Shading into an icon would be acceptable, I think. At least for me. Not for me, I'm afraid. The really neat things about shading is that the title bar shows the name of the app and open document (icons get less and less like an indication of the type of app and more like a an advertising logo as time goes by) and also show the width of the open window.
Created attachment 177922 [details] attachment-1721701-0.html Ancient computer history: before the invention of the task bar, minimizing a window was also called "iconifying" the window; it would minimize to an icon. So in reality, "shading to an icon" is just a second way of minimizing and isn't shading at all. On February 3, 2025 11:05:31 AM UTC, Alan Prescott <bugzilla_noreply@kde.org> wrote: >https://bugs.kde.org/show_bug.cgi?id=377162 > >--- Comment #38 from Alan Prescott <alanjprescott@gmail.com> --- >(In reply to Matija Šuklje from comment #34) >> Shading into an icon would be acceptable, I think. At least for me. > >Not for me, I'm afraid. The really neat things about shading is that the title >bar shows the name of the app and open document (icons get less and less like >an indication of the type of app and more like a an advertising logo as time >goes by) and also show the width of the open window. > >-- >You are receiving this mail because: >You are on the CC list for the bug.
(In reply to Alec Habig from comment #29) > Just switched to Wayland because Plasma 6 with Fedora 40, and overall it's > "just fine". Had been avoiding the X->Wayland upgrade for years, was > pleasantly surprised at things overall/ > > However, I just encountered this bug. If it's to be considered an > unimplemented feature rather than a bug, could it be removed from the > options in "Settings->Window Management", which still lists "shade" as a > thing you can assign to, for example double clicking on the titlebar? As per my a comment I made earlier, shading seems to work (for me) for Edge and Chrome. There may be other applications, too, but I haven't found them yet. I can even control the behaviour with System Settings -> Window Behaviour -> Titlebar Actions. I won't pretend to understand the technicalities of modern windowing systems, but I'd be completely happy if only all my windows behaved exactly like Edge and Chrome. Thanks and regards
For me, although some windows do shade, the rest of the environment doesn't notice. So, if you try to interact with whatever was behind the "shade" window before it shaded, no luck. Acts as if the window manager doesn't know the window shaded and all the input still goes to the shaded window.
(In reply to Alec Habig from comment #41) > For me, although some windows do shade, the rest of the environment doesn't > notice. So, if you try to interact with whatever was behind the "shade" > window before it shaded, no luck. Acts as if the window manager doesn't > know the window shaded and all the input still goes to the shaded window. Yes, same for me. Good spot! What I find confusing is that the fact that System Settings->Window Behaviour->Titlebar Actions seems to work, and will shade, maximise vertically, maximise horizontally, etc., suggests the windowing manager does know about the window. On the other hand, your observation seems to suggest it doesn't (or, at least, not fully). Clearly, there must be something different about the window for these applications, but it's not obvious to me what it is.
Could someone please explain why a window could not be made to have a height of 1 pixel, its same width, and a 0% opacity? I've seen people say that having shading work is very difficult but have not seen any explanations of why this is the case. Perhaps there is logic they have not thought of? I'd like to hear about the logic that has been evaluated but rejected, please.
(In reply to Matthew Sheffield from comment #43) A better place to ask about design questions like this are on the forums: https://discuss.kde.org/c/help/6 The bug tracker isn't intended for discussion about design.
(In reply to TraceyC from comment #44) > (In reply to Matthew Sheffield from comment #43) > A better place to ask about design questions like this are on the forums: > https://discuss.kde.org/c/help/6 > > The bug tracker isn't intended for discussion about design. I believe Matthew Sheffield's comment (#43) is pertinent to this discussion since he is looking for a reason the suggestion he is indirectly making would not work to enable "shading" under Wayland. So far it seems we hear "no one uses this" or "it's difficult" but no attempt to find a technique, workaround, or alternative.
(In reply to Matthew Sheffield from comment #43) > Could someone please explain why a window could not be made to have a height > of 1 pixel, its same width, and a 0% opacity? I've seen people say that > having shading work is very difficult but have not seen any explanations of > why this is the case. Perhaps there is logic they have not thought of? I'd > like to hear about the logic that has been evaluated but rejected, please. That would be better than nothing, but it's not a perfect reimplementation. Currently, AFAICT, the application doesn't see the window's height as changing when it's shaded. Making it so that its height is changed to 1px would make it try to rearrange its content, and then rearrange it back when it's unshaded, so there may be a brief visual glitch. And many windows have a minimum height, which we'd have to override, which might cause unpredictable behavior in the application, though it's unlikely to cause major problems.
(In reply to Peter from comment #40) > (In reply to Alec Habig from comment #29) > > Just switched to Wayland because Plasma 6 with Fedora 40, and overall it's > > "just fine". Had been avoiding the X->Wayland upgrade for years, was > > pleasantly surprised at things overall/ > > > > However, I just encountered this bug. If it's to be considered an > > unimplemented feature rather than a bug, could it be removed from the > > options in "Settings->Window Management", which still lists "shade" as a > > thing you can assign to, for example double clicking on the titlebar? > > As per my a comment I made earlier, shading seems to work (for me) for Edge > and Chrome. There may be other applications, too, but I haven't found them > yet. I can even control the behaviour with System Settings -> Window > Behaviour -> Titlebar Actions. I won't pretend to understand the > technicalities of modern windowing systems, but I'd be completely happy if > only all my windows behaved exactly like Edge and Chrome. > > Thanks and regards Sorry for the late answer, but my humble guess is, that those apps manage windows on their own (I've done this once in the past). That is possible, but has other downsides. This is yet another reason to implement shading, since it is one reason less to implement your own window management. Also, since Wayland seems wanting to take over the X11 world, it would be good to ask the developers of such apps, what functionally they're missing. Guess, it's full control over the top bar.
(In reply to Grósz Dániel from comment #46) > That would be better than nothing, but it's not a perfect reimplementation. > Currently, AFAICT, the application doesn't see the window's height as > changing when it's shaded. Making it so that its height is changed to 1px > would make it try to rearrange its content, and then rearrange it back when > it's unshaded, so there may be a brief visual glitch. And many windows have > a minimum height, which we'd have to override, which might cause > unpredictable behavior in the application, though it's unlikely to cause > major problems. Exactly, 1 px height would cause an unexpected state in an app which announces a minimal height for a reason. The special height handling is the major reason why developers are so reluctant to implement shading. In the end, the world splits in two groups: One group says: shading is such a nice feature, that is worth the conditional code to implement. You will find all the old fars in this group (like me), that will stick to X as long as it's possible. The other group says, this will add some ugly conditional code in an important area, that we need to carry around until some other technology emerge. All developers, responsible of this code are in this group. As long as there is no overlap between these groups, nothing will happen.
(In reply to Hans-Peter Jansen from comment #47) > (In reply to Peter from comment #40) > > As per my a comment I made earlier, shading seems to work (for me) for Edge > > and Chrome. There may be other applications, too, but I haven't found them > > yet. I can even control the behaviour with System Settings -> Window > > Behaviour -> Titlebar Actions. I won't pretend to understand the > > technicalities of modern windowing systems, but I'd be completely happy if > > only all my windows behaved exactly like Edge and Chrome. > > > > Thanks and regards > > Sorry for the late answer, but my humble guess is, that those apps manage > windows on their own (I've done this once in the past). > That is possible, but has other downsides. This is yet another reason to > implement shading, since it is one reason less to implement your own window > management. Also, since Wayland seems wanting to take over the X11 world, it > would be good to ask the developers of such apps, what functionally they're > missing. Guess, it's full control over the top bar. When these apps use client-side decorations, I doubt they support shading. If they are configured to use server-side decorations, and shading works, isn't that most likely because they use XWayland? And if you want all apps to support shading, can't you set some environment variables so that all apps use XWayland? I still use X11, so I haven't tried this, but AFAIUI this bug only affects native Wayland windows, and if I were to switch to kwin-wayland, making apps use it through XWayland is what I'd try to keep shading work.
I posted this as a Kubuntu bug some time ago. It's still true now, and may be more relevant being here. Shading is one of the most productive features of a Plasma desktop. (I see my wife struggling with looking at info on two windows on Microsoft Windows and realize how easy shading + reveal-on-hover makes this). However, for a Wayland session in 24.10 it is not enabled for most windows. My double-click on the title bar does not work, and the option is greyed out in the title-bar menu. It (oddly?) is enabled for some windows - namely those running wine, but even there it is not perfect as: o The hover functions works over the area of the full (hidden) window, not just the visible title-bar o Some windows minimize rather than shade. Loss of the ability to shade makes the desktop considerably less useful. So, to me, the loss of this feature is a big loss in productivity. Probably not for people who run with maximized windows all of the time (what I think of as "Walls" not windows), but for those who wish to interact with multiple windows concurrently this loss is a disaster.
(In reply to Gordon Lack from comment #50) > I posted this as a Kubuntu bug some time ago. > It's still true now, and may be more relevant being here. > > Shading is one of the most productive features of a Plasma desktop. > (I see my wife struggling with looking at info on two windows on Microsoft > Windows and realize how easy shading + reveal-on-hover makes this). > > However, for a Wayland session in 24.10 it is not enabled for most windows. > My double-click on the title bar does not work, and the option is greyed out > in the title-bar menu. > > It (oddly?) is enabled for some windows - namely those running wine, but > even there it is not perfect as: > o The hover functions works over the area of the full (hidden) window, not > just the visible title-bar > o Some windows minimize rather than shade. > > Loss of the ability to shade makes the desktop considerably less useful. > > So, to me, the loss of this feature is a big loss in productivity. > Probably not for people who run with maximized windows all of the time (what > I think of as "Walls" not windows), but for those who wish to interact with > multiple windows concurrently this loss is a disaster. Just to echo Gordon's comment, I found shading very helpful and used to use it a lot. If there were a way of reintroducing it with Wayland, it would be much appreciated.
(In reply to Peter from comment #51) > (In reply to Gordon Lack from comment #50) > > I posted this as a Kubuntu bug some time ago. > > It's still true now, and may be more relevant being here. > > > > Shading is one of the most productive features of a Plasma desktop. > > (I see my wife struggling with looking at info on two windows on Microsoft > > Windows and realize how easy shading + reveal-on-hover makes this). > > > > However, for a Wayland session in 24.10 it is not enabled for most windows. > > My double-click on the title bar does not work, and the option is greyed out > > in the title-bar menu. > > > > It (oddly?) is enabled for some windows - namely those running wine, but > > even there it is not perfect as: > > o The hover functions works over the area of the full (hidden) window, not > > just the visible title-bar > > o Some windows minimize rather than shade. > > > > Loss of the ability to shade makes the desktop considerably less useful. > > > > So, to me, the loss of this feature is a big loss in productivity. > > Probably not for people who run with maximized windows all of the time (what > > I think of as "Walls" not windows), but for those who wish to interact with > > multiple windows concurrently this loss is a disaster. > > Just to echo Gordon's comment, I found shading very helpful and used to use > it a lot. If there were a way of reintroducing it with Wayland, it would > be much appreciated. Same for me, I am (was?) using shading a lot and now that it's not there anymore I not sure how to compensate this. For me, what is important, that I can minimize the window but it keeps being at its place. A minimizing window that goes to the panel is not really helpful as I have a hard time identifying it again (lots of terminals for example).
I've used Linux for 33 years and counting, and have very frequently used the "Window Shade" feature in many window-managers, with KDE and KDE Plasma, and many other window managers. But, outright disabling it when people clearly use and WANT to use it, is kinda ridiculous.
It wasn't disabled. It's not supported by the wayland protocol, which delegates control of a window to the client. There is an open MR, but it seems that it hasn't been worked in about 3 years: https://invent.kde.org/plasma/kwin/-/merge_requests/1183 Even to get that MR ready would take a lot of work, and there's no clear benefit. Firstly, shading would require a protocol extension to communicate window state to client applications to avoid unnecessary client reflow. Second, it would introduce even more complexity to the boxes KWin needs to track per-window. Third, it would only work when you're running on the KWin compositor, since Mutter/etc don't have plans to implement it. Forth, it would only work with KDE applications. To sum up, there's a substantial amount of downstream complexity that this would introduce. It's not clear to the current KWin maintainer that implementing the feature is worth that complexity. They're the one that would be fielding bugs for all of the edge-cases that don't work.
(In reply to ✨ Audrey ✨ from comment #54) > It wasn't disabled. It's not supported by the wayland protocol, which > delegates control of a window to the client. There is an open MR, but it > seems that it hasn't been worked in about 3 years: > https://invent.kde.org/plasma/kwin/-/merge_requests/1183 > > Even to get that MR ready would take a lot of work, and there's no clear > benefit. Firstly, shading would require a protocol extension to communicate > window state to client applications to avoid unnecessary client reflow. I don't know the technical details (like what "control of a window" means), but can't the window manager just hide the contents of the window below the title bar (and pass through mouse events) when it's shaded, without the application knowing anything about it? If transparency effects can work, hiding the contents of the window should be possible, if no other way then by making it fully transparent. Idk about passing through mouse events, but don't they go through the window manager/compositor?
(In reply to ✨ Audrey ✨ from comment #54) > It wasn't disabled. It's not supported by the wayland protocol, which > delegates control of a window to the client. Which makes it odd that when I first tried a Wayland session, some windows (Wine ones?) actually COULD shade! The fact that most could not is why I switched back to X11 very quickly. > Even to get that MR ready would take a lot of work, and there's no clear > benefit. There is a VERY CLEAR benefit. Shading is the most productive feature on a KDE desktop.
(In reply to Gordon Lack from comment #56) > (In reply to ✨ Audrey ✨ from comment #54) > > It wasn't disabled. It's not supported by the wayland protocol, which > > delegates control of a window to the client. > > Which makes it odd that when I first tried a Wayland session, some windows > (Wine ones?) actually COULD shade! > The fact that most could not is why I switched back to X11 very quickly. > > > Even to get that MR ready would take a lot of work, and there's no clear > > benefit. Based on earlier comments, AFAIK shading works under kwin_wayland for applications that use XWayland (an X11 compatibility layer), rather than native Wayland windows. It should be possible to tell all apps to use XWayland by setting some environment variables (clear WAYLAND_DISPLAY, or set toolkit-specific ones like QT_QPA_PLATFORM?); openSUSE for a few years shipped two KDE Wayland sessions, a "full wayland" one that had apps that support Wayland use native Wayland windows, and one that used kwin_wayland, but had apps connect to it using the X11 protocol, i.e. use XWayland.
(In reply to ✨ Audrey ✨ from comment #54) > Third, it would only work when you're running on the KWin > compositor, since Mutter/etc don't have plans to implement it. Forth, it > would only work with KDE applications. Those are non-reasons. Why care about Mutter/etc, that used to be a KWin and KDE feature for ages. Mutter/Gnome cares much about Plasma/KDE applications? And regarding the "forth" reason: so it had been working with KDE/Qt applications, and people were happy about it. Now it doesn't work at all no matter what the origin of the app is. That's called regression.
Regarding Wayland-specific difficulties, is it of interest that labwc supports window shading? Their general approach to Wayland protocols is stated as: > Labwc only understands wayland-protocols & wlr-protocols, > and cannot be controlled with dbus, sway/i3-IPC, or other technology. > The reason for this is that we believe that custom IPCs and protocols > create a fragmentation that hinders general Wayland adoption. Their description of the shade action: > Set, unset, or toggle, respectively, the "shaded" state of the active window. > When shaded, window contents are hidden, leaving only the titlebar visible. > Full-screen windows or those without server-side decorations > (including those for which the server-side titlebar has been hidden) > are not eligible for shading.
With the prevalence of CSDs we cannot reliably do shading for enough apps to provide a reliable experience. I would reject all patches attempting to add it.
This seems perverse. Shading is done from the title bar. So, if you have a title bar surely all you have to do is remove (unmap) the window and preserve the title bar. Which isn't client related, but all in the window manager.
(In reply to David Edmundson from comment #60) > With the prevalence of CSDs we cannot reliably do shading for enough apps to > provide a reliable experience. I would reject all patches attempting to add > it. What is a "prevalence of CSDs"? You mean client side decorations? But KDE has enough apps with SSDs to benefit from this feature. Neglection is kinda OK if you don't like it, but why pushing back reasonable efforts if any? This has always been a toggleable option (never enabled by default), no one was hurt by its presence. It could be kept this way too if ever re-introduced again.
(In reply to David Edmundson from comment #60) > With the prevalence of CSDs we cannot reliably do shading for enough apps to > provide a reliable experience. I would reject all patches attempting to add > it. That makes no sense. Anyone who uses a mixture of SSD and CSD apps has to accept anyway that CSD apps look different, and offer different features (typically less features, only the lowest common denominator of minimize, maximize and close) from SSD apps. (Even if you were to only use CSD apps, CSD apps written with different toolkits will look and possibly behave different, one of the downsides of CSD.) That this also applies to this particular feature, shading, doesn't make anything worse. Meanwhile, AFAIK, KDE stuck to SSD in part precisely because it's possible to offer more features and customization than with CSD. And CSDs aren't all that prevalent under KDE. KDE apps and (most) Qt apps use SSD, even non-GNOME GTK apps like GIMP and Inkscape use SSD under KDE. The most prominent apps that use CSD by default under KDE, browsers and VS Code/ium, can be easily configured to use SSD. GNOME apps are the only ones I've encountered that can't be configured to use SSD, and there's rarely a reason to use them under KDE, as there's usually a better KDE or otherwise non-GNOME equivalent. Even if it can't work with CSD windows, it makes no sense to reject a patch that add it for those of us who would like to use it with SSD windows. Are you going to remove the ability to add "Keep above" and "All desktops" buttons to the titlebar too, because they won't be available on CSD windows anyway? I hope if someone would otherwise implement it, he'll still do so, and publish it as a soft fork.
Created attachment 186992 [details] attachment-1041013-0.html Talk about arrogance. In the window paradigm, only a few desktops ever REQUIRED a similar look and feel for all windows. Apple was the worst offender for that. I suggest that if Edmundson wants a similar look and feel, he should go get himself a Mac and stop mucking up KDE. On November 20, 2025 11:23:04 AM UTC, David Edmundson <bugzilla_noreply@kde.org> wrote: >https://bugs.kde.org/show_bug.cgi?id=377162 > >David Edmundson <kde@davidedmundson.co.uk> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > Resolution|--- |INTENTIONAL > CC| |kde@davidedmundson.co.uk > Status|CONFIRMED |RESOLVED > >--- Comment #60 from David Edmundson <kde@davidedmundson.co.uk> --- >With the prevalence of CSDs we cannot reliably do shading for enough apps to >provide a reliable experience. I would reject all patches attempting to add it. > >-- >You are receiving this mail because: >You are on the CC list for the bug.
Handling CSD apps is IMO outside scope for this issue. But since their existence is being used as justification for the regression, I must note here that it's currently possibly to force GTK apps with CSD to instead use KWin SSD: https://codeberg.org/MorsMortium/GTK-NoCSD Currently that is only relevant for those who install it and customize their app launchers to use it, but it indicates that theoretically Plasma/KWin could offer a similar feature in the future. I use that project to "fix" Meld and Handbrake. Even if I couldn't do that, I would still much prefer to keep the feature for all apps excepting those than to lose it over concern for them.
This might be outside the scope of what KDE is willing to support, but has anyone considered if it's feasible to pursue an extension to wayland that would let apps communicate shading? A protocol extension would allow CSD and SSD providers to coordinate. Apps with SSD would be able to shade their client areas. Apps with CSD would be able to shade themselves. This feature was, at one time, supported by most KDE applications. It relied upon X11, which won't work. And the existing MR introduces complexity that doesn't seem justified by kwin's current maintainers. If, however, it were a wayland protocol extension, implementable by any compositor, and natively implemented by KDE's window primitives, would that affect the decision to mark this RESOLVED-INTENTIONAL? If not, then as much as we all desire the feature, we need to accept that it's lost.
From a quick look at the proposed patch - and obviously without having the full picture - it’s true that it would add some complexity. But it's code for the sake of people's convenience, not the other way around, right? IMHO, as long as: - shading is off by default, - users get a clear message about limitations and SSD/CSD complications before enabling it, - the implementation doesn’t introduce impossible-to-maintain logic and limits some weird edge cases like resizing a shaded window, then it’s worth doing.
(In reply to Taras Oleksyn from comment #67) > From a quick look at the proposed patch - and obviously without having the > full picture - it’s true that it would add some complexity. > But it's code for the sake of people's convenience, not the other way > around, right? > > IMHO, as long as: > - shading is off by default, > - users get a clear message about limitations and SSD/CSD complications > before enabling it, > - the implementation doesn’t introduce impossible-to-maintain logic and > limits some weird edge cases like resizing a shaded window, > > then it’s worth doing. Why did you change the resolution to fixed? I don't know how well the patch works, but in any case, as long as it's not integrated, the bug is not fixed.
(In reply to Grósz Dániel from comment #68) > (In reply to Taras Oleksyn from comment #67) > > From a quick look at the proposed patch - and obviously without having the > > full picture - it’s true that it would add some complexity. > > But it's code for the sake of people's convenience, not the other way > > around, right? > > > > IMHO, as long as: > > - shading is off by default, > > - users get a clear message about limitations and SSD/CSD complications > > before enabling it, > > - the implementation doesn’t introduce impossible-to-maintain logic and > > limits some weird edge cases like resizing a shaded window, > > > > then it’s worth doing. > > Why did you change the resolution to fixed? I don't know how well the patch > works, but in any case, as long as it's not integrated, the bug is not fixed. Apologies, that was unintentional, reverted the status.
My scenario is also one where almost every app I use (LibreOffice, mpv, Firefox, VSCode, virt-manager, Dolphin, Konsole, KWrite, Krita, Okular, EasyEffects, qpwgraph, OBS Studio) all either use SSD by default or can support it by enabling something in their settings pages, the only exception is Steam, and even in that case I can force enable decorations and it works fine since unlike the GNOME stuff it doesn't bother with shadows. So not supporting shading because apps exist that use CSDs seems like throwing the baby out with the bathwater, unless KDE too plans to start using CSD only in at least some apps in the future.
I'm probably off the wall with this but. KDE offers to show the window without title-bar and frame, would it be possible to ONLY show title-bar and fame - i.e. with an invisible click-through main panel? It wouldn't be exactly the same as shading but not far off, especially if the frame were very narrow.
Elsewhere it's been said in justification for this regression: > I'm also 100% sure we can find a UX that's actually better than window shading and providing the workflow people actually want. > Something that actually works for csd apps and actually gets out the way when you want it out the way. I would be happy with the current (X11) behavior, or a modification wherein a shaded window is always keep-above, and intelligently un-keep-aboves itself. But if this issue is closed intentionally, with the justification that an improved replacement feature is possible, is there any existing issue to track for that improved replacement feature?
Is there any possibility to implement something that would simulate shading? Maybe force resize the height to 1 pixel or something... Like others here my GUI workflow of 15+ years is destroyed by this missing feature... I postponed moving to Wayland as long as I could but it's not really possible now on my new laptop. Wayland is really a user-facing regression :(
Regarding my recurring KDE e.V. donation, I wrote this letter to the KDE board right now: Hi KDE-Board, I just wanted to let you know, that KDE, my favorite desktop for 26 years, is about to pass away from my workstation/laptops due to the move away from X. With the Wayland based desktop, it is missing an essential feature: https://bugs.kde.org/show_bug.cgi?id=377162. With that, it feels stupid to keep up with my quarterly donation to KDE e.V. What a pity. Be assured, that without this feature, a lot of people will turn away from KDE. While looking like a minor feature difference to many, for those that use it in their daily routines, it will be missed badly. Either, we change our habits completely, or find an alternative desktop (window manager), that will still provide it. BR I understand, that the real solution is an extension to the Wayland protocol. It's really sad, that those, that are in charge of it, don't care about their users, or try to enforce specific behaviors.
> is there any existing issue to track for that improved replacement feature? I still read this thread
(In reply to David Edmundson from comment #75) > > is there any existing issue to track for that improved replacement feature? > > I still read this thread Do I understand correctly then that the path to a replacement feature starts with: Someone who uses window shading should come up with a new UX that you like, and describe it here? If so, what do you think of window shading, modified such that shaded windows always act like keep-above?
(In reply to Hans-Peter Jansen from comment #74) > Regarding my recurring KDE e.V. donation, I wrote this letter to the KDE > board right now: > > Hi KDE-Board, > > I just wanted to let you know, that KDE, my favorite desktop for 26 years, > is about to pass away from my workstation/laptops due to the move away from > X. With the > Wayland based desktop, it is missing an essential feature: > https://bugs.kde.org/show_bug.cgi?id=377162. > > With that, it feels stupid to keep up with my quarterly donation to KDE e.V. > > What a pity. > > Be assured, that without this feature, a lot of people will turn away from > KDE. While looking like a minor feature difference to many, for those that > use > it in their daily routines, it will be missed badly. Either, we change our > habits completely, or find an alternative desktop (window manager), that > will > still provide it. > > BR > > I understand, that the real solution is an extension to the Wayland protocol. > It's really sad, that those, that are in charge of it, don't care about > their users, > or try to enforce specific behaviors. Hey Hans-Peter, et-al., I hear your frustration and understand the desire to pull the ripcord to escape the KDE/Wayland debacle. Wanting a Wayback Machine (Peabody's Improbable History) journey to when the adults were still in the KDE room? The Trinity Desktop Environment (TDE), born as a independent fork of KDE 3.5 in 2010. https://trinitydesktop.org 2025.11.09: TDE R14.1.5 released! TDE reclaims KDE in the glory days, before the eyecandy-bloat and regression du jour De-Vo. My 2-head workstation and the rest of our Gentoo-based servers and desktops have been ever so happy with TDE. So yeah, bailing to a viable alternative is reasonable and easy- sorted in less than an hour. BTW, TDE/TQt and KDE/Qt co-exist fine within the same boxen, if one desires such. Gentoo and Arch have nice TDE How-To pages to get started. https://wiki.gentoo.org/wiki/Trinity_Desktop_Environment BR
Created attachment 187707 [details] attachment-1665693-0.html On 12/16/25 10:12 AM, Jeff Hayes wrote: > Hey Hans-Peter, et-al., I hear your frustration and understand the desire to > pull the ripcord to escape the KDE/Wayland debacle. > > Wanting a Wayback Machine (Peabody's Improbable History) journey to when the > adults were still in the KDE room? > The Trinity Desktop Environment (TDE), born as a independent fork of KDE 3.5 in > 2010. > https://trinitydesktop.org > 2025.11.09: TDE R14.1.5 released! > > TDE reclaims KDE in the glory days, before the eyecandy-bloat and regression du > jour De-Vo. > My 2-head workstation and the rest of our Gentoo-based servers and desktops > have been ever so happy with TDE. > So yeah, bailing to a viable alternative is reasonable and easy- sorted in less > than an hour. > BTW, TDE/TQt and KDE/Qt co-exist fine within the same boxen, if one desires > such. > > Gentoo and Arch have nice TDE How-To pages to get started. > https://wiki.gentoo.org/wiki/Trinity_Desktop_Environment > > BR > The TDE project-maintained Arch Linux binary repository returns a 404. I don't have time to compile an entire DE.
> If so, what do you think of window shading, modified such that shaded windows always act like keep-above? Not sure exactly what this means, but for me the idea of shading is that the title bars end up below things. i.e. out of the way, but easily findable when wanted.
(In reply to vbhunt from comment #78) > The TDE project-maintained Arch Linux binary repository returns a 404. I > don't have time to compile an entire DE. I'm with you on not wanting to suffer building an entire DE and the associated. Only those crazy-Gentoo aficionados (self-own) suffer such. ;-> I don't have an active Arch install at present to test; however, the Arch Trinity Repository Installation Instructions https://wiki.trinitydesktop.org/Arch_Trinity_Repository_Installation_Instructions infers reference to binary repo (where $arch=x86_64): https://mirror.ppa.trinitydesktop.org/trinity/archlinux/x86_64/ There, one finds the prebuilt x86_64 TDE packages. Does this repo suffice? :-) BR
Created attachment 187742 [details] attachment-1994298-0.html On 12/17/25 5:41 AM, Jeff Hayes wrote: > ...reference to binary repo (where $arch=x86_64): > https://mirror.ppa.trinitydesktop.org/trinity/archlinux/x86_64/ > There, one finds the prebuilt x86_64 TDE packages. > Does this repo suffice? :-) That repo was the one returning a 404 to pacman.