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.