Add a "Auto-hide when windows are close / Hide when needed" like Visibility option on panel settings, which is an modification and additional alternative of current "Auto-hide" Visibility option. This behavior is implemented currently in Cinnamon, and is very useful because when the Plasma Desktop isn't with any windows, or they are placed at a distance of the panel, it stays visible. Reproducible: Always Steps to Reproduce: Current Implementation: 1. In plasma, add a panel and set its visibility to auto-hide. 2. When you're done, it should disappear as expected. Expected Results: 1. In plasma, add a panel and in addition to the auto-hide visibility option, choose something like "Hide when needed". 2. If there aren't any windows near the panel when "Hide when needed" is set, the panel stays visible. Else, the panel hides itself.
Adding the VDG team for comment. Personally I'm not a fan of having a billion different config options, we'll end up with some which get untested, unsupported and broken, like the current windows can cover option which I'm fixing.
*** Bug 351988 has been marked as a duplicate of this bug. ***
Big huge fan of these request. Currently plasma 5 panel "hidding" is completly unusable to me. Autohide makes all the sliding messages popups ( notifications ) look horrible ( as with KDE4 ) Worse, setting "Keep Below" does not work like in KDE4, since when this setting, If a window is maximized and is on top of the panel, one cannot quickly make the panel visible by triggering the panel edge ( like it was possible in KDE4 ). If intelihide was possible, i would definitely use it.
I would also love this feature to be implemented in the plasma workspace. It is one of the features i love in cinnamon/XFCE. I also know lot of others who would like to see this feature in KDE. Please make this happen.
*** Bug 362065 has been marked as a duplicate of this bug. ***
I also think intelligent autohide (i.e. visible panel when it is not in the way) is good design. @David Edmundson: I understand the comment about not having too much options. Maybe having intelligent autohide instead of plain hiding would help to have a good design without adding an option? I can't think of any usecase where plain hide is better than intelligent autohide. The latter is: - more discoverable (panel is visible at startup when no window is shown) - quickest (anytime the panel is not in the way, it is already available for interaction) - more elegant (but that's admittedly a personal and relative opinion)
(In reply to flyos from comment #6) > I also think intelligent autohide (i.e. visible panel when it is not in the > way) is good design. > > @David Edmundson: I understand the comment about not having too much > options. Maybe having intelligent autohide instead of plain hiding would > help to have a good design without adding an option? > > I can't think of any usecase where plain hide is better than intelligent > autohide. The latter is: > - more discoverable (panel is visible at startup when no window is shown) > - quickest (anytime the panel is not in the way, it is already available for > interaction) > - more elegant (but that's admittedly a personal and relative opinion) I fully agree. there is not a single case in which plain hiding is better than autohiding. I started to use the Plank dock for this reason, plain hiding in Plasma feels a decade old!
*** Bug 371174 has been marked as a duplicate of this bug. ***
*** Bug 368385 has been marked as a duplicate of this bug. ***
Well, I haven't updated this bug since I reported it, but I can emulate the desired behaviour with the option "Window Can Cover" since a while. What happens is, if there are maximized windows or windows that are close to the panel, the window will be on top of the panel, making it hidden, if you pass the mouse cursor on the corner where the panel is, it will show it's "shadow", and if you put the pointer on the edge where the panel is, it'll appear. It's pretty handy, helping with the screen real state. And if there are no maximized windows (or windows touching the panel's borders) the panel will be shown fully. I think the only thing it doesn't do is have the "intelligent" label and a auto hide embedded with this behaviour, which I don't mind at all. Shall we close this?
Another thing is that this need is now covered by Latte-Dock which can now act as as a "panel on steroid", rather than being limited to being a dock. One could think having this available to download easily is enough, or that this feature from Latte-Dock should be merged to "regular" panel. I'll admit I don't really have an opinion on this, since I switched to Latte-Dock...
(In reply to flyos from comment #11) > Another thing is that this need is now covered by Latte-Dock which can now > act as as a "panel on steroid", rather than being limited to being a dock. > > One could think having this available to download easily is enough, or that > this feature from Latte-Dock should be merged to "regular" panel. I'll admit > I don't really have an opinion on this, since I switched to Latte-Dock... Interesting... Actually, the OP of bug #368385 is the dev of Latte-Dock (bug opening in 2016).
> Interesting... Actually, the OP of bug #368385 is the dev of Latte-Dock (bug opening in 2016). one of the reasons that I created Now Dock(ancestor of Latte) back then was that missing feature from plasma. Just to add, Now Dock started at August of 2016 and Latte is just 1.4 years old (it started in December of 2016)
So, the question still stand: shall we consider the availability of Latte-Dock as a "fix" and close the bug? OP seems to be inclined to close it.
(In reply to flyos from comment #14) > So, the question still stand: shall we consider the availability of > Latte-Dock as a "fix" and close the bug? OP seems to be inclined to close it. No, since it's not a native panel from plasma. But it [Latte-Dock] does have a few additional behaviours on their own. I would close this right now saying that a similar approach was implemented, but I'm waiting for confirmation on my previous comment #c10 (comment 10) by third parties. I may even do it before that, when I have more free time to review everything.
(In reply to Tony from comment #10) > Well, I haven't updated this bug since I reported it, but I can emulate the > desired behaviour with the option "Window Can Cover" since a while. > What happens is, if there are maximized windows or windows that are close to > the panel, the window will be on top of the panel, making it hidden, if you > pass the mouse cursor on the corner where the panel is, it will show it's > "shadow", and if you put the pointer on the edge where the panel is, it'll > appear. It's pretty handy, helping with the screen real state. And if there > are no maximized windows (or windows touching the panel's borders) the panel > will be shown fully. I think the only thing it doesn't do is have the > "intelligent" label and a auto hide embedded with this behaviour, which I > don't mind at all. > Shall we close this? I'm not sure when this happened, but I clearly remember this working correctly. It seems that is not the case anymore. Having a maximized window completely blocks the panel and the panel stays behind the window even when you move the mouse to the screen edge...
(In reply to @rchUser from comment #16) > (In reply to Tony from comment #10) > > Well, I haven't updated this bug since I reported it, but I can emulate the > > desired behaviour with the option "Window Can Cover" since a while. > > What happens is, if there are maximized windows or windows that are close to > > the panel, the window will be on top of the panel, making it hidden, if you > > pass the mouse cursor on the corner where the panel is, it will show it's > > "shadow", and if you put the pointer on the edge where the panel is, it'll > > appear. It's pretty handy, helping with the screen real state. And if there > > are no maximized windows (or windows touching the panel's borders) the panel > > will be shown fully. I think the only thing it doesn't do is have the > > "intelligent" label and a auto hide embedded with this behaviour, which I > > don't mind at all. > > Shall we close this? > > I'm not sure when this happened, but I clearly remember this working > correctly. It seems that is not the case anymore. Having a maximized window > completely blocks the panel and the panel stays behind the window even when > you move the mouse to the screen edge... Ahaa, found the issue. I changed the "Switch desktop on edge" option to "always" which explains why the panel was reluctant to display - even though I don't have a 2 row desktop setup. Seems like the screen edge feature hijacks these events in this case. Anyways, as long as you use either "Disabled" or "Only when moving Windows" option, the behavior is exactly like @Tony described - behind windows, but displays if user moves mouse to the edge.
Just curious: 1. How will "intelligent autohide" interact with maximized but inactive windows? Currently I have 4 desktops each running a maximized Firefox and I only see my desktop once a week on reboot - so I guess, the "intelligent" part is totally lost on me unless the panel is allowed to cover inactive windows. 2. What about the side-by-side layout via Meta+Cursor Left/Right? Should this in addition show the "intelligent autohide" panel or shall it be covered?
*** Bug 462733 has been marked as a duplicate of this bug. ***
(In reply to flyos from comment #14) > So, the question still stand: shall we consider the availability of > Latte-Dock as a "fix" and close the bug? OP seems to be inclined to close it. From my side this bug can be closed. I am happy with the option 'windows can go below'.
(In reply to flyos from comment #14) > So, the question still stand: shall we consider the availability of > Latte-Dock as a "fix" and close the bug? OP seems to be inclined to close it. Since Latte-dock is dead (or at least not in a usable state right now and I don't see a bright future for that project) latte-dock is not fix for this bug. And honestly, I would love to see this feature in "native" Plasma panel (which can now easily replace latte-dock with his new floating option). The thing is, there is no reason to "autohide" panel when there is no window blocking the space where the panel is. And it looks kind of odd in my opinion.
It's a legitimate request that we'll keep open. :)
(In reply to Nate Graham from comment #22) > It's a legitimate request that we'll keep open. :) I agree, it would really make sense to do this.
Excuse me if I'm being stupid - I am not a programmer - but with luck, I can imagine, for plasma you could at least look for inspiration in the code of Latte-Dock. Or even copy it? If I remember well, this functionality worked very well in Latte-Dock...
Created attachment 158536 [details] Space for "intelligently hide" in the new UI It is as if there is already made space for this feature in future UI (attachment)
(In reply to PK from comment #24) > Excuse me if I'm being stupid - I am not a programmer - but with luck, I can > imagine, for plasma you could at least look for inspiration in the code of > Latte-Dock. Or even copy it? > If I remember well, this functionality worked very well in Latte-Dock... I can imagine it doesn't have to be that easy as said... Kde and Latte-Dock could use different implementations. But I never looked into plasma nor latte-dock code so it's just my guess. (In reply to PK from comment #25) > Created attachment 158536 [details] > Space for "intelligently hide" in the new UI > > It is as if there is already made space for this feature in future UI > (attachment) That looks pretty good. What version of KDE is this?
*** Bug 434487 has been marked as a duplicate of this bug. ***
> That looks pretty good. What version of KDE is this? This is the, in these days non existing, Plasma 6. I used the image from Nate Graham's blog https://pointieststick.com/2023/04/28/this-week-in-kde-the-bug-slaughterfest-continues/ . Every saturday morning he publishes a new one. Always interesting to read.
With Plasma 6 removing the go above and go below window options for panels, this is a feature that really must be added by the release of Plasma 6.
*** Bug 426840 has been marked as a duplicate of this bug. ***
How is "intelligent autohide" different from the now-implemented "Windows can cover" Is there any difference in functionality? Or is this simply a new name, a new implementation, and the same functionality?
Basically, when any windows touch the panel, it enters "Auto-Hide" mode automatically. This is different from the current "Auto-Hide" mode in which the panel is always hidden unless deliberately shown, or the current "Windows Can Cover" mode where the panel simply becomes covered up, and never actually hides.
(In reply to Nate Graham from comment #32) > Basically, when any windows touch the panel, it enters "Auto-Hide" mode > automatically. This is different from the current "Auto-Hide" mode in which > the panel is always hidden unless deliberately shown, or the current > "Windows Can Cover" mode where the panel simply becomes covered up, and > never actually hides. In that light "intelligent auto-hide" is also "intelligent not-hide" because the panel stays visible as long as it is not in the way.
(In reply to Nate Graham from comment #32) > Basically, when any windows touch the panel, it enters "Auto-Hide" mode > automatically. Question: isn't it so that the panel doesn't "intelligently hide" for a non-active window? If I'm not mistaking that was the behavior in Latte-Dock. I think when I was using e.g. firefox full screen there (panel hidden) and I opened another application that not took so much of the screen, the panel appeared over firefox. But when I closed this active application and firefox became the active application again, then the panel would immediately auto-hide again.
I can't comment on how the "Intelligent Auto-Hide" feature is implemented because it hasn't been implemented yet! :)
I feel like this is bad communication by now. First, I invested quite some time into tracking and documenting half a dozen issues related to "windows can cover" and it does seem, it is essentially unmaintained for quite some time now. If it was clear that it was gonna be discontinued, a little note could have helped, at least when I issued the first "windows can cover issue" Then, you seem to discontinue one feature, to introduce another one that does almost the same thing: I don't see the point here at all. How is "hiding" different from "can be covered" Does it animate the hide? I am a bit puzzled, as to what I should expect. To me, that smells like the previous version was just a messy implementation, and now we are launching the same product under a different name to address that. Also in order to clarify the state for other contributors as well, I would welcome a public statement around that issue, thanks a lot.
I'm sorry you feel your time was wasted by reporting issues in a feature that's going to be removed in the next version of Plasma. That decision wasn't made until recently, so I'm afraid there was no way to provide earlier notice of it. Sometimes that's just the way things shake out. The point of the new feature is to work properly--or at least, as well as the current Auto-Hide feature works. By re-using its code, plus code for the pre-existing feature to turn the panel opaque when touched, we gain the ability implement a "Dodge Windows" feature in a way that exercises existing codepaths, which means they get used and tested more and become more robust over time. It also hopefully looks and behaves more nicely, and closer to what people are expecting, given that an identical feature already exists on some other platforms. This is in contrast to the "Windows Can Cover" feature which has its own separate codepath that almost never gets used (it was believed to be the least-frequently used of the visibility modes) and behaved in a rather awkward way. So yes, it would be fairly accurate to say that the old feature had a messy and buggy implementation, and it's being "re-launched" in the form of a new feature that offers a slightly different interaction model and visual presentation with more robust code.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3508
Git commit 105c2c15a5c619e9d963373b338f25cfcc5e4150 by Bharadwaj Raju. Committed on 16/11/2023 at 19:53. Pushed by bharadwaj-raju into branch 'master'. Add "Dodge Windows" visibility mode for the panel Adds a new mode called "Dodge Windows" in which the panel is usually visible but hides itself when a window would touch it. FIXED-IN: 6.0 M +23 -6 shell/panelview.cpp M +3 -0 shell/panelview.h M +5 -0 shell/scripting/panel.cpp M +4 -1 shell/shellcorona.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/105c2c15a5c619e9d963373b338f25cfcc5e4150
Git commit 7ce3f197be30c445ee9d9a4c298439b1995d5aa5 by Bharadwaj Raju. Committed on 16/11/2023 at 19:53. Pushed by bharadwaj-raju into branch 'master'. Implement UI to enable "Dodge Windows" mode for the panel Depends on https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3508. This adds the configuration UI and tweaks the limit for deciding whether a window is touching to be 12px instead of 6px. After testing various values for it, I found 12px is the smallest that prevents glitches with window snapping.  M +36 -13 desktoppackage/contents/configuration/PanelConfiguration.qml M +20 -4 desktoppackage/contents/views/Panel.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/7ce3f197be30c445ee9d9a4c298439b1995d5aa5