Bug 267277 - configurable delay for autohide/show of panels
Summary: configurable delay for autohide/show of panels
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Panel (show other bugs)
Version: master
Platform: Ubuntu Linux
: VHI wishlist
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
: 197043 198030 254453 257173 277920 297109 300144 302888 314962 316324 330248 351561 376313 412292 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-02-27 22:57 UTC by Mario J. Barchéin Molina
Modified: 2023-12-01 22:58 UTC (History)
54 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.0


Attachments
panel blue effect while mouse is far from the screen border (panel on right) (7.71 KB, image/jpeg)
2012-07-03 20:17 UTC, Xavier Brochard
Details
Suggested implementation (33.25 KB, image/png)
2013-02-12 04:37 UTC, Mike Vaughn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mario J. Barchéin Molina 2011-02-27 22:57:44 UTC
Version:           unspecified (using KDE 4.5.1) 
OS:                Linux

It would be great if user could define delay time for autohide and autoshow of panels when autohide option is selected for some panel.

Currently, panel show instantly when mouse is on the edge of the screen, which is annoying in some cases. I would like to specify "show after 1000msec" to avoid accidental panel shows. The same behaviour would be neat for autohide. For example for any panel, I would like to configure:

  - Autoshow delay:   1000msec
  - Autohide after:   1500msec

I have seen requests for this feature in forums but not here in bugs.kde.org

Thank you very much



Reproducible: Didn't try
Comment 1 jos poortvliet 2011-04-09 23:48:03 UTC
I'd say this is a dup of bug 254453 :D
Comment 2 Christoph Feck 2011-07-19 15:00:12 UTC
*** Bug 254453 has been marked as a duplicate of this bug. ***
Comment 3 Christoph Feck 2011-07-19 15:00:33 UTC
*** Bug 277920 has been marked as a duplicate of this bug. ***
Comment 4 Alejandro Nova 2011-11-02 13:12:39 UTC
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.
Comment 5 Alejandro Nova 2011-11-02 13:13:23 UTC
*** This bug has been confirmed by popular vote. ***
Comment 6 Manolete 2012-02-01 18:23:49 UTC
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)
Comment 7 Thijs 2012-06-22 09:40:44 UTC
*** Bug 198030 has been marked as a duplicate of this bug. ***
Comment 8 Dotan Cohen 2012-06-22 13:55:26 UTC
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.
Comment 10 Dotan Cohen 2012-07-03 08:37:50 UTC
*** Bug 300144 has been marked as a duplicate of this bug. ***
Comment 11 Dotan Cohen 2012-07-03 08:38:20 UTC
*** Bug 302888 has been marked as a duplicate of this bug. ***
Comment 12 Dotan Cohen 2012-07-03 08:38:45 UTC
*** Bug 257173 has been marked as a duplicate of this bug. ***
Comment 13 Dotan Cohen 2012-07-03 08:39:18 UTC
*** Bug 297109 has been marked as a duplicate of this bug. ***
Comment 14 Dotan Cohen 2012-07-03 08:40:51 UTC
Thank you Apache, I reviewed those bugs and marked as dupe where appropriate.
Comment 15 Xavier Brochard 2012-07-03 20:15:49 UTC
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.
Comment 16 Xavier Brochard 2012-07-03 20:17:20 UTC
Created attachment 72310 [details]
panel blue effect while mouse is far from the screen border (panel on right)
Comment 17 Xavier Brochard 2012-07-03 20:22:21 UTC
 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
Comment 18 Xavier Brochard 2012-07-03 20:26:51 UTC
 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.
Comment 19 ceolesen 2012-07-03 22:31:31 UTC
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.
Comment 20 apache 2012-07-04 06:44:54 UTC
@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.
Comment 21 apache 2012-07-04 07:08:16 UTC
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.
Comment 22 Felix Miata 2012-07-04 11:57:14 UTC
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.
Comment 23 apache 2012-07-06 12:01:41 UTC
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.
Comment 24 moenshendrik 2012-12-12 12:09:58 UTC
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)
Comment 25 Mike Vaughn 2013-02-12 04:37:49 UTC
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.
Comment 26 Craig Sillva 2013-02-21 01:08:01 UTC
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!
Comment 27 Jekyll Wu 2013-02-21 01:58:39 UTC
*** Bug 197043 has been marked as a duplicate of this bug. ***
Comment 28 Jekyll Wu 2013-02-21 01:59:12 UTC
*** Bug 314962 has been marked as a duplicate of this bug. ***
Comment 29 Tuukka Verho 2013-02-21 14:59:42 UTC
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.
Comment 30 Dotan Cohen 2013-02-21 17:13:06 UTC
> 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.
Comment 31 Tuukka Verho 2013-02-21 17:30:58 UTC
(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.
Comment 32 ceolesen 2013-02-21 17:54:20 UTC
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.
>
Comment 33 Tuukka Verho 2013-02-21 18:06:04 UTC
(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...
Comment 34 ceolesen 2013-02-21 19:22:56 UTC
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.
Comment 35 Tuukka Verho 2013-02-21 21:15:39 UTC
> 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.
Comment 36 ceolesen 2013-02-21 22:03:37 UTC
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.
>
Comment 37 nick 2013-02-21 22:11:21 UTC
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.
Comment 38 Tuukka Verho 2013-02-21 22:19:40 UTC
> 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.
Comment 39 Tuukka Verho 2013-02-21 22:31:44 UTC
(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.
Comment 40 ceolesen 2013-02-21 22:55:52 UTC

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.
>
Comment 41 Brian C. Milco 2013-02-23 04:12:39 UTC
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.
Comment 42 Jason Sauders 2013-02-23 04:28:33 UTC
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.
Comment 43 Tuukka Verho 2013-02-23 16:44:07 UTC
The "pressure" approach does sound feasible. Basically the mouse has to stay at the screen edge for a fixed time while still moving.
Comment 44 Dotan Cohen 2013-02-23 16:56:24 UTC
> 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.
Comment 45 ceolesen 2013-02-23 23:45:26 UTC
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.
>
Comment 46 Jekyll Wu 2013-03-07 16:23:22 UTC
*** Bug 316324 has been marked as a duplicate of this bug. ***
Comment 47 gandalf3 2013-03-15 20:51:21 UTC
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.
Comment 48 Tuukka Verho 2013-03-15 20:59:50 UTC
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/
Comment 49 apog 2013-12-28 12:38:58 UTC
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
Comment 50 Brandon Garlock 2013-12-30 05:01:53 UTC
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.
Comment 51 Christoph Feck 2014-02-09 18:54:17 UTC
Note that "keep pushing the mouse" does not work on systems that use a stylus.
Comment 52 nick 2014-02-09 19:15:40 UTC
(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.
Comment 53 Dotan Cohen 2014-02-10 07:29:09 UTC
> 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.
Comment 54 Serhiy Zahoriya 2014-02-10 11:02:50 UTC
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.
Comment 55 Christoph Feck 2014-02-10 11:59:24 UTC
> 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.
Comment 56 Christoph Feck 2015-08-22 15:44:06 UTC
*** Bug 351561 has been marked as a duplicate of this bug. ***
Comment 57 eemantsal 2016-04-21 20:43:09 UTC
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.
Comment 58 Hugh Williams 2017-05-28 14:48:51 UTC
Would it not be sensible to register this as a bug in plasmashell now as development on plasma 4 has ceased?
Comment 59 Nate Graham 2018-01-23 21:56:06 UTC
*** Bug 330248 has been marked as a duplicate of this bug. ***
Comment 60 David Edmundson 2018-04-11 19:28:04 UTC
*** Bug 376313 has been marked as a duplicate of this bug. ***
Comment 61 gudvinr+kde 2020-02-23 19:59:20 UTC
Any improvements for this one?
This is really infuriating if you have hidden dock-ish panels
Comment 62 Ed_FR38 2020-02-23 20:27:32 UTC
Light a candle and pray... or install Latte-Dock
Comment 63 ahangarha 2020-05-14 00:16:17 UTC
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.
Comment 64 Bob 2021-03-14 01:00:40 UTC
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.
Comment 65 Simplissimus 2021-04-17 22:26:37 UTC
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?
Comment 66 Nate Graham 2022-06-25 20:13:31 UTC
*** Bug 412292 has been marked as a duplicate of this bug. ***
Comment 67 Uladzislau 2022-10-04 21:16:25 UTC
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 .
Comment 68 evea 2022-11-05 23:50:00 UTC
Since latte dock is gone, this would be a really important feature to implement. I personally like to set both values to 0.
Comment 69 gazbaz 2022-11-17 17:45:56 UTC
 I have to agree with Latte gone and Cairo Dock very old, this would be  great feature !
Comment 70 Nico 2022-11-19 09:41:00 UTC
+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.
Comment 71 Alex 2022-12-10 20:49:12 UTC
In the meanwhile I made a script to simulate "autoshow delay" behaviour.
https://gist.github.com/LatinSuD/da71e5821dfa248213e6c91129228b1a
Comment 72 Bug Janitor Service 2023-11-19 07:46:34 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4664
Comment 73 Vlad Zahorodnii 2023-12-01 08:09:38 UTC
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