Bug 267277

I'd say this is a dup of bug 254453 :D

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

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

Since this bug is where the discussion will continue, I think this is not a wish, but an usability bug, and it must be marked as such.

When I have, for instance, an extra-wide Microblog applet in a panel set on Autohide, on the right side of the screen, and I try to reach the scroll bar and hit the screen border, I trigger the Microblog, essentially rendering that feature unusable.

What should happen is:

1. I move my cursor to the screen border.
2. The screen border glows. I can correct my mousing.
3. 2 seconds (one and a half, one, but please, no less than that) later, the Microblog panel appears.

*** This bug has been confirmed by popular vote. ***

I totally agree, with you, Alejandro. This issue affects clearly to usability. Trying to type a text search into a webpage in Firefox, Qupzilla or any other browser which places its text search tool in the lower border is a pain if every now and then the panel is showing up whenever you try to place your pointer in the search box. A delay configuration tool, like we have for configuring screen border actions, doesn't seem too difficult to do, no? (I modestly say this from my absolute ignorance regarding programation)

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

Note that earlier bug #198030 was marked as a dupe of this one. That bug is full of use cases and support from many users, and even contains a patch.

https://bugs.kde.org/show_bug.cgi?id=297109
https://bugs.kde.org/show_bug.cgi?id=257173
https://bugs.kde.org/show_bug.cgi?id=300144
https://bugs.kde.org/show_bug.cgi?id=302888 
https://bugs.kde.org/show_bug.cgi?id=267277
This is a really hot bug :)

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

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

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

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

Thank you Apache, I reviewed those bugs and marked as dupe where appropriate.

There is also a problem of desktop consistency, because kwin hot corners are a bit hard to activate (which is good) while panel show instantly. 
In fact, the blue effect shown before panel activation, appear while the mouse is far from screen border (see attachment). In the attchment below, panel is on the right of the sreen.

Created attachment 72310 [details]
panel blue effect while mouse is far from the screen border (panel on right)

 I would like to add that Aaron Seigo <a href="https://bugs.kde.org/show_bug.cgi?id=198030#c14">comment</a> from #198030 (duplicate) contains wrong assertions:

"that said, i really don't think it is worth making the before/after duration configurable. if steady hands are an issue, don't use autohiding panels. "

With web sites increasing the minimum width of web pages, this is absurd on 15'' screens.

"if the timeout is to short in general, we can increase it. but these kinds of options just lead to more configuration UI for the benefit of a very small group of people at the cost of everyone else."

A large majority of users are noobs. People thanever reports bugs but complains to the sysadmin that KDE is hard to use. I'm a sysadmin for small companies, where we users

 I would like to add that Aaron Seigo <a href="https://bugs.kde.org/show_bug.cgi?id=198030#c14">comment</a> from #198030 (duplicate) contains wrong assertions:

"that said, i really don't think it is worth making the before/after duration configurable. if steady hands are an issue, don't use autohiding panels. "

With web sites increasing the minimum width of web pages, this is absurd on 15'' screens.

"if the timeout is to short in general, we can increase it. but these kinds of options just lead to more configuration UI for the benefit of a very small group of people at the cost of everyone else."

A large majority of users are noobs. People that never reports bugs. I'm a sysadmin for several small companies, and when someone complains about KDE, it is often because of these sort of glitches that disturb them.

I have steady hands. But move the mouse around quickly. And moving the
mouse up to the top of the display with the intention of grabbing a
window located there by its top bar it is easy to move just that
little too far thereby accidently hitting the top edge of the display
with the result that an auto-hide panel hidden there immediately
exposes itself without delay. And then to get it to go away again so
you get to the top bar of the window now under the exposed panel you
move the mouse down but the panel does not go away immediately because
there is a delay on the hide. Why is there a delay on the hide but
none on the expose? If KDE doesn't want to make more config options
(I'm aware of the argument that KDE has too many config options) then
I suggest that the delay be put on the expose instead of the hide. Or
at least be removed from the hide.
The other thing is that the same auto-hide panel exposed at the top
doesn't hide by just moving the mouse just below its lower edge but
has to be moved well below. Why is that?



On Tue, Jul 3, 2012 at 10:26 PM, Xavier Brochard <xavier@alternatif.org> wrote:
> https://bugs.kde.org/show_bug.cgi?id=267277
>
> --- Comment #18 from Xavier Brochard <xavier@alternatif.org> ---
>  I would like to add that Aaron Seigo <a
> href="https://bugs.kde.org/show_bug.cgi?id=198030#c14">comment</a> from #198030
> (duplicate) contains wrong assertions:
>
> "that said, i really don't think it is worth making the before/after duration
> configurable. if steady hands are an issue, don't use autohiding panels. "
>
> With web sites increasing the minimum width of web pages, this is absurd on
> 15'' screens.
>
> "if the timeout is to short in general, we can increase it. but these kinds of
> options just lead to more configuration UI for the benefit of a very small
> group of people at the cost of everyone else."
>
> A large majority of users are noobs. People that never reports bugs. I'm a
> sysadmin for several small companies, and when someone complains about KDE, it
> is often because of these sort of glitches that disturb them.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

@Aaron J. Seigo 2010-03-10 04:47:41 UTC
"that said, i really don't think it is worth making the before/after duration configurable. if steady hands are an issue, don't use autohiding panels. "

Very, very bad attitude towards users. Users are not monkeys or drunks with shaking hands. We just have different preferences.

"if the timeout is to short in general, we can increase it. but these kinds of options just lead to more configuration UI for the benefit of a very small group of people at the cost of everyone else."
"very small group of people" - how did you counted it
Not everyone reports bug, not everyone use auto-hide option. Very false assumption.
"at the cost of everyone else" - very untrue statement. There are no cost for other users at all. If options are implemented users can just choose. ZERO cost for users. More work for developers though. That's the source of the concern, I guess.

ceolesen 2012-07-03 22:31:31 UTC

"I'm aware of the argument that KDE has too many config options"

I use KDE just because it has options and I can customize it. That's an advantage over other DE. Options mean freedom of choice.

"...then I suggest that the delay be put on the expose instead of the hide. Or at least be removed from the hide."
I recommend options. When developers choose to give only one solution there are going to be immediately another bug reports from disgruntled users. So please give options both for show and hide. Another idea would be to make it show while click on the edge of the screen while make it disappear immediately or with custom time delay.

Sorry one more comment. Waiting until it will show up seems not the best solution for me either. Don't put any forced time delay on show or make it optional for those who prefer to wait. I would choose "click screen edge" option and show immediately. This way it would work when I want and don't disturb when I don't use it.

With the current absent configurability, the autohide function to me is unusable, making Bug 158556 - "Manual hiding of panel" all the more important, and because still not fixed, keeps most of my time spent running KDE3 instead.

One more thing worth mentioning. I have auto-hide panel at the top of the screen. Currently I cannot maximize it because when I wanted to close an application by pressing kwin close button I frequently hit the top of the screen causing the panel to show. Someone may call it "shaking hands" syndrome but when I work I don't want to pay much attention to very precise mouse movements. If I hit the upper screen edge accidentally I don't want it to disturb me in my work (by forcing me to wait until it hides).
I would be very grateful if panel could have delay options and show while screen edge clicked option.

This has always been a very annoying problem for me. 

Using fullscreen applications that have something close to the edge of the screen in combination with auto-hiding panels is quite frankly completely unusable. So I really believe this should be considered a usability bug. For panels on the left this is e.g. a problem for Inkscape which has tool buttons to the far left. For panels on the top this gets even worse as it becomes impossible to use the window controls without the panel opening.

My original workaround was to stop maximizing windows at all (which is a decent solution on high resolution screens and thanks to the awesome alt+right mouse click window resize possiblity).

Now I however have a smaller laptop with lower resolution screen, and this is no longer a feasible solution due to the reduced screen resolution. I also notice I trigger the panel a lot more often due to the laptop touchpad which is less accurate than a mouse.

I'd also like to point out that i have my kickoff in the top left corner of the screen, where I also have the present windows effect configured. I have never triggered that one by accident due to the slight (configurable) delay. Merely adding a delay to showing panels that is equal to that of the hot corners could resolve this issue, and that solution would not add additional configuration options.

I *really* like auto-hiding panels as they make it possible to keep the desktop a lot cleaner, and more importantly as it leaves more screen area free. This bug occurs often enough and is annoying enough that I have actually considered moving to Unity as an alternative desktop environment due to this, as it does have auto-hiding panels with a delay. (After trying I came back to KDE however as I cannot live without some of its more awesome features. I merely mention this to indicate that this is more than just a "wish" item but rather an actual bug)

Created attachment 77182 [details]
Suggested implementation

I did a mock-up showing how this option could be implemented in a user-friendly manner, at reasonably little "cost" to the users who won't use it.

Here is how gnome implemented it at one point [1].

An option to consider would be to borrow some of the implementation of snapping windows, which respond to the pressure of putting a window up against the edge of the screen. Doing that same thing but when not 'holding' a window would reveal a hidden panel. In the Window settings there are options for the number of pixels affected by the 'border snap', which seems like a good analog to the reveal delay being requested by users [2].

Cheers,
Craig

[1] https://lh3.ggpht.com/_doBHNuxZcyg/SDSwJ9EF9EI/AAAAAAAAASs/ari4fYgL9Dg/s1600-h/gnome_configuration_editor.jpg

[2] Me too!

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

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

What about adding a small delay (if there isn't any already) and not showing the panel if a mouse click is detected during the delay (e.g. if you click on a close button or a search bar)? A click should be an obvious sign that the user does not mean to unhide the panel. And the other way around: if you don't click on anything, why would the mouse be at the screen edge if not to access the panel?

I kinda agree with Aaron that adding a config option would only benefit a small (although passionate) group of power users. The rest of us would probably just disable autohide instead of trying to tinker with the settings and figure out what is the optimal delay for me. However this is just a gesture recognition problem and hardly an impossible one to solve in a way that it would work for everyone.

> if you don't click on anything, why would the mouse be at the screen edge if not to access the panel?

Because users 'throw' the mouse aside (also called 'parking' the mouse) so that it won't interfere when they type or do other things on the screen.

(In reply to comment #30)
> > if you don't click on anything, why would the mouse be at the screen edge if not to access the panel?
> 
> Because users 'throw' the mouse aside (also called 'parking' the mouse) so
> that it won't interfere when they type or do other things on the screen.

Ok, well I guess that would be indistinguishable from a deliberate panel unhiding gesture. A delay would not help here either, though.

I like the idea of the mouse click but instead of a delay i.e. just
dragging the mouse to the edge would not unhide the panel until also the
mouse is clicked while the mouse is on the edge.


On Thu, Feb 21, 2013 at 6:30 PM, Tuukka Verho <tyverho@cc.hut.fi> wrote:

> https://bugs.kde.org/show_bug.cgi?id=267277
>
> --- Comment #31 from Tuukka Verho <tyverho@cc.hut.fi> ---
> (In reply to comment #30)
> > > if you don't click on anything, why would the mouse be at the screen
> edge if not to access the panel?
> >
> > Because users 'throw' the mouse aside (also called 'parking' the mouse)
> so
> > that it won't interfere when they type or do other things on the screen.
>
> Ok, well I guess that would be indistinguishable from a deliberate panel
> unhiding gesture. A delay would not help here either, though.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

(In reply to comment #32)
> I like the idea of the mouse click but instead of a delay i.e. just
> dragging the mouse to the edge would not unhide the panel until also the
> mouse is clicked while the mouse is on the edge.

You are suggesting the opposite of what my idea was: I proposed that the panel would _not_ unhide if the mouse if clicked, you would unhide the panel only if the mouse _is_ clicked...

Yes (realizing that it would reserve the pixels along the edge for the
purpose but only if configured as such). Alternatively, perhaps a gesture
could be used - like hitting the border twice to unhide the panel?

Your proposal if I understand correctly is for preventing the panel from
unhiding but for the case of while the mouse is parked at the edge. That'ss
a different issue in my mind.

What I was looking for is for the panel to not unhide unless intended
because of the delay to wait for for the panel to again hide.
Again, here is a user case
1. close all windows
2. place an auto hide panel along the top edge of the display (I have a
menu of most used apps on that panel as an alternative to the menus down
under the start button in the lower left corner)
3. launch say chrome. It will show up along the top edge of the display by
default. I have chrome configured to not use the system title bars and
borders in order to not waste window space on that. Open tabs in chrome
such that the entire width of chrome is covered by tabs - thereby leaving a
very thin top border for drag of chrome.
4. now move chrome down a little by grabbing its top window border i.e.
move the mouse up onto that thin top border of chrome without hitting the
top edge of the window. Because if the top edge is hit then that will
immediately unhide the panel thereby covering the chrome window border and
once unhidden then there is an unconditional delay to wait for until the
panel again hides. Yes - hitting that thin border is challenging without
hitting the edge especially if you're busy moving the mouse around quickly.
Erratic mouse movements by elderly users are not going to make it any
easier.

> What I was looking for is for the panel to not unhide unless intended
> because of the delay to wait for for the panel to again hide.
> Again, here is a user case

I think my suggestion would alleviate your problem. Let's say there would be a 200-300ms default delay for unhiding. If you're going to drag the window, you'll probably click on the window titlebar within the delay period, and the panel wouldn't show up at all.

I should've paid better attention - I thought I was in a thread originating
at my  own duplicate bug report here
https://bugs.kde.org/show_bug.cgi?id=297109
But as you can see from that then - I agree with you. I there suggested the
same approach as you - a configurable delay. And there both on the hide and
unhide.
Another idea comes to mind - a 2nd hit on the edge could toggle the effect
of the 1st hit i.e. could undo the unhide immediately thereby avoiding the
delay.



On Thu, Feb 21, 2013 at 10:15 PM, Tuukka Verho <tyverho@cc.hut.fi> wrote:

> https://bugs.kde.org/show_bug.cgi?id=267277
>
> --- Comment #35 from Tuukka Verho <tyverho@cc.hut.fi> ---
> > What I was looking for is for the panel to not unhide unless intended
> > because of the delay to wait for for the panel to again hide.
> > Again, here is a user case
>
> I think my suggestion would alleviate your problem. Let's say there would
> be a
> 200-300ms default delay for unhiding. If you're going to drag the window,
> you'll probably click on the window titlebar within the delay period, and
> the
> panel wouldn't show up at all.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

1) the KDE designers have chosen to make the start panel a key piece of the UX similar to other systems--thus *every* user must access it
2) not all users have the same preference regarding how they want to interact with it
3) the mere fact that this debate is still occurring, attempting to find a single common-denominator-behavior to satisfy everyone, is proof that none exists--thus this *must* be solved via configurable behavior choices.

Simply making it behave differently is just going to keep the bug going with a different set of users now unsatisfied.

> But as you can see from that then - I agree with you. I there suggested the
> same approach as you - a configurable delay. And there both on the hide and
> unhide.

You are still not reading me carefully. I'm not suggesting to make the delay configurable, just have some short but fixed delay (and no unhiding if a click is detected).

I don't have strong opinions though, because I've never used autohiding panels (probably due to the problems mentioned here) and I'm not a plasma developer. Maybe in the future when we have a QML panel it'll be easier to experiment and come up with smart behavior that'd make autohiding usable for us all.

(In reply to comment #37)
> Simply making it behave differently is just going to keep the bug going with
> a different set of users now unsatisfied.

Yes, surely there'll always be unsatisfied users. However, the real question is how big this set of users is. I strongly believe that by good design one can greatly reduce the number.

> 3) the mere fact that this debate is still occurring, attempting to find a
> single common-denominator-behavior to satisfy everyone, is proof that none
> exists--thus this *must* be solved via configurable behavior choices.

I cannot see how the debate proves anything other than it is easy to come up with ideas but harder to implement them. I'm hopeful, though, that this could be changed in the future when you can just edit the QML file and share it with others.

Adding configuration options wouldn't make everyone happy. It wouldn't make the unhiding feature usable for me because I always go with default options: tinkering with the settings after every install is too much hassle. And I believe the majority of users share the sentiment.

On Thu, Feb 21, 2013 at 11:19 PM, Tuukka Verho <tyverho@cc.hut.fi> wrote:

> https://bugs.kde.org/show_bug.cgi?id=267277
>
> --- Comment #38 from Tuukka Verho <tyverho@cc.hut.fi> ---
> > But as you can see from that then - I agree with you. I there suggested
> the
> > same approach as you - a configurable delay. And there both on the hide
> and
> > unhide.
>
> You are still not reading me carefully. I'm not suggesting to make the
> delay
> configurable, just have some short but fixed delay (and no unhiding if a
> click
> is detected).
>
> I don't have strong opinions though, because I've never used autohiding
> panels
> (probably due to the problems mentioned here) and I'm not a plasma
> developer.
> Maybe in the future when we have a QML panel it'll be easier to experiment
> and
> come up with smart behavior that'd make autohiding usable for us all.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

My 2 cents--

If you've used OS X 10.7 or 10.8 and you put an App in full screen mode when you throw the mouse to the bottom it doesn't trigger the dock, even if you leave it at the bottom of the screen. You have to keep pushing the mouse down off the screen for some fixed distance (or time?), and then it shows the Dock. I'd probably shorten the trigger distance, but otherwise I think it works pretty well.

I agree with Brian 100%. To further compare, if I may, Unity has this feature as well. It makes working with Unity's auto hide a real treat because you can set the exact amount of "pressure" the screen edge must feel before activating it. That way you can dial it in exactly how you see fit. With the current KDE panel auto hide, it's THAT much of a pain that I flat out don't use it anymore. I don't mean to play the "they have it, so should KDE" card, but all comparisons aside this feature just *makes sense*. To be completely candid, there's just no other way to word it.

The "pressure" approach does sound feasible. Basically the mouse has to stay at the screen edge for a fixed time while still moving.

> Basically the mouse has to stay at the screen edge for a fixed time while still moving.

I cannot find the bug right now, but I had suggested something similar to this for the "drag-to-top-of-screen-then-maximize" plasma feature years ago. I fully support this.

I just came across this
http://forum.kde.org/viewtopic.php?f=68&t=87254
which mentions the same idea and also another way it used to work.


On Sat, Feb 23, 2013 at 5:56 PM, Dotan Cohen <kde-2011.08@dotancohen.com>wrote:

> https://bugs.kde.org/show_bug.cgi?id=267277
>
> --- Comment #44 from Dotan Cohen <kde-2011.08@dotancohen.com> ---
> > Basically the mouse has to stay at the screen edge for a fixed time
> while still moving.
>
> I cannot find the bug right now, but I had suggested something similar to
> this
> for the "drag-to-top-of-screen-then-maximize" plasma feature years ago. I
> fully
> support this.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

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

I have also been rather annoyed at this (the instant autoshow) for a while,
I rather like the way this is handled in unity, with a single setting for the "autoshowiness" of the panel. (which seems to take into account some sort of "mouse velocity/pressure" or something)
so more or less what was suggested earlier..
Also the "glow" that appears in kde when you cursor is near the screen edge, instead fave that appear depending on how close you are to opening the panel, in terms of "mouse pressure".
Though a simple delay would imho be an improvement over what it is now.

As far as the hiding delay goes, what it is now works well for me, (I'm using KDE 4.10.1 with archlinux x86 64) which seems to be about for a little less than a second, so it gets out of the way pretty well, but it won't go away when your cursor is within a few pixels, or on a preview.

Martin Graesslin says that screen edge handling will be done by KWin in Plasma2:

http://blog.martin-graesslin.com/blog/2013/03/an-update-on-kwin-on-5/

hi

i also feel very annoyed with this instant showup of the taskbar and request a user-adjustable time for autohide/show.

cheers and happy new year

My 2 cents is that I like the way Unity does autohide of the taskbar. I have to push against the side for a second and then the panel appears. Also it is smart when I am using multiple monitors to stop my mouse if I am slowing down as I approach the edge of a monitor in a way that is indicative of an attempt to show panel.

Note that "keep pushing the mouse" does not work on systems that use a stylus.

(In reply to comment #51)
> Note that "keep pushing the mouse" does not work on systems that use a
> stylus.

Sure, but let's not fall into the trap of developing for the least common denominator. There can be multiple mechanisms that each make the most sense for their given environment.

> Note that "keep pushing the mouse" does not work on systems that
> use a stylus.

Neither does right-clicking, but a work around was developed: long-clicking. Likewise, one could "keep pushing the mouse" by leaving the stylus for some time at the edge of the screen, i.e. long-clicking the last pixel. Or stylii-equipped devices could revet to current behaviour and mouse-equipped devices could enjoy the new feature.

Is it just me or is it usually quite hard to get to last pixel of the screen on touchscreens with stylus? Thus I don't think having autohiding panels on them is a good idea.

> Neither does right-clicking

Wrong, it even supports middle-clicking. "Long-clicking" hinders productivity.

> Thus I don't think having autohiding panels on them is a good idea.

I am using autohiding since KDE 4 implemented it (was it KDE 4.2?) and used it on KDE 3 also. Wacom drivers allow calibration.

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

In KDE/Plasma 5 there's the same design mistake that the oroginal poster reported 5 years ago: the panel shows up inmediately when you pass the pointer a couple of milimeters from the bottom border of the screen or you touch the border with the pointer.
Is a real pain in the ass: when you are moving your pointer by the lower area of your creen there shows up the panel every now and then, and you have to move your mouse away, wait for some tenths of second for the panel to hide agan, and come back with your mouse, but being very careful for not going too near to the bottom of your screen and make the panel show up again.
I like the idea proposed by Brandon Garlock in december of 2013: not to show the panel until one really touches the bottom border. Obviously it's not the unique solution, a simple delay would be another. We can configure delays for the upper screen border actions (show grid, window, etc), why not for the panel in the lower one? Is it very hard task? One would not think so, but who knows, I know nothing about programming; but anyway, I think is a serious important deffect in desktop "mechanics" design for all those users who like to use all their screen size and avoid distractions. Please reconsider it.

Would it not be sensible to register this as a bug in plasmashell now as development on plasma 4 has ceased?

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

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

Any improvements for this one?
This is really infuriating if you have hidden dock-ish panels

Light a candle and pray... or install Latte-Dock

As of now, on Kubuntu 20.04 which uses Kde Plasma 5.18.4, implementation of hot corners is somehow detecting pressure. They wont get activated by moving mouse to them but but putting little pressure.

I think if the same thing be implemented for panels would work.

This is also an issue when using Barrier KVM. If a panel resides on an edge between 2 adjacent screens, it always unhides whenever moving from one screen to the other. For reasons unknown this causes the cursor to jump halfway across the destination screen every few times. The only solution atm is to move the panel to a different screen edge.

Yes, please include this functionality. It is a real nuisance when you set your panels to auto-hide to gain screen space and have a less cluttered desktop, and then when the pointer grazes the edge of the screen the panel pops up instantaneously to annoy and interrupt the workflow; and the same when the pointer is removed for a fraction of a second from the panel and it hides at full speed and you need to lose time and patience to get it back.

Latte Dock permits this configuration, but unfortunately it's a RAM devoring thing. Couldn't the Latte's code be copied, or something simple like that, to achieve this functionality?

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

This option will be pretty important to have . I am designer and mouse (or stylus) that moves all over the screen is a ordinary thing for me. And having such delay is mandatory .

Since latte dock is gone, this would be a really important feature to implement. I personally like to set both values to 0.

 I have to agree with Latte gone and Cairo Dock very old, this would be  great feature !

+1 to this! Latte was providing this feature previously, it really improves usability and causes less irritations when Plasma dock/panels are hiding much too early.

In the meanwhile I made a script to simulate "autoshow delay" behaviour.
https://gist.github.com/LatinSuD/da71e5821dfa248213e6c91129228b1a

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

Git commit e5753ea33669813f2ba0cf23f28b4cf06ac259f3 by Vlad Zahorodnii, on behalf of Bharadwaj Raju.
Committed on 01/12/2023 at 09:09.
Pushed by vladz into branch 'master'.

Make autohide screen edges use the same activation delay setting as other edges

Makes it possible to easily target things in a window near your panel edge,
without bringing up your panel.

The `m_client` condition this MR removes appears to have been added solely to make autohiding panels appear instantly. See https://invent.kde.org/plasma/kwin/-/commit/c4140d6f4e5cd953023f2c078088d20a553ab875.

M  +10   -2    autotests/integration/layershellv1window_test.cpp
M  +11   -4    autotests/integration/screenedges_test.cpp
M  +1    -1    src/screenedge.cpp

https://invent.kde.org/plasma/kwin/-/commit/e5753ea33669813f2ba0cf23f28b4cf06ac259f3

(In reply to Vlad Zahorodnii from comment #73)
> Git commit e5753ea33669813f2ba0cf23f28b4cf06ac259f3 by Vlad Zahorodnii, on
> behalf of Bharadwaj Raju.
> Committed on 01/12/2023 at 09:09.
> Pushed by vladz into branch 'master'.
> 
> Make autohide screen edges use the same activation delay setting as other
> edges
> 
> Makes it possible to easily target things in a window near your panel edge,
> without bringing up your panel.
> 
> The `m_client` condition this MR removes appears to have been added solely
> to make autohiding panels appear instantly. See
> https://invent.kde.org/plasma/kwin/-/commit/
> c4140d6f4e5cd953023f2c078088d20a553ab875.
> 
> M  +10   -2    autotests/integration/layershellv1window_test.cpp
> M  +11   -4    autotests/integration/screenedges_test.cpp
> M  +1    -1    src/screenedge.cpp
> 
> https://invent.kde.org/plasma/kwin/-/commit/
> e5753ea33669813f2ba0cf23f28b4cf06ac259f3

Hey, I just tried on kde(In reply to Vlad Zahorodnii from comment #73)
> Git commit e5753ea33669813f2ba0cf23f28b4cf06ac259f3 by Vlad Zahorodnii, on
> behalf of Bharadwaj Raju.
> Committed on 01/12/2023 at 09:09.
> Pushed by vladz into branch 'master'.
> 
> Make autohide screen edges use the same activation delay setting as other
> edges
> 
> Makes it possible to easily target things in a window near your panel edge,
> without bringing up your panel.
> 
> The `m_client` condition this MR removes appears to have been added solely
> to make autohiding panels appear instantly. See
> https://invent.kde.org/plasma/kwin/-/commit/
> c4140d6f4e5cd953023f2c078088d20a553ab875.
> 
> M  +10   -2    autotests/integration/layershellv1window_test.cpp
> M  +11   -4    autotests/integration/screenedges_test.cpp
> M  +1    -1    src/screenedge.cpp
> 
> https://invent.kde.org/plasma/kwin/-/commit/
> e5753ea33669813f2ba0cf23f28b4cf06ac259f3

Hey, I just checked on a fresh Endeavor OS install (seems like I ended up with KDE 6.0.3), and the issue does not appear to be fixed.

Moreover, I have questions that this commit is related to the issue: this seems to concern the "activation delay" setting in the "Screen Edge" settings, but even after lowering it, it doesn't seem to affect the unhide delay of an auto hidden panel. This makes me question if this ticket was marked as fixed by mistake because as far as I can test, I don't notice the problem being remedied in any way, nor can I find a way to configure the hide/unhide delay (especially unhide which is my main problem I noticed with this issue).

Is it possible to get details on how this commit fixes this issue?

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