Bug 367440

Summary:	Client screen edge activation autohide delay
Product:	[I don't know] kde	Reporter:	eemantsal <infmtk>
Component:	general	Assignee:	Unassigned bugs mailing-list <unassigned-bugs>
Status:	CLOSED INTENTIONAL
Severity:	normal	CC:	kde
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description eemantsal 2016-08-17 17:41:27 UTC

Fist of all, excuse me if I'm duplicating bugs, I already posted here 4 months ago: https://bugs.kde.org/show_bug.cgi?id=267277 but that bug dates from 2011 and nobody seems to have taken any care of it, so I have the impression it's a "necrobug". Anyway, if you consider it appropriate don't hesitate to mark this one of mine as a duplicate.

Ok, here I go.
We can configure actions for our screen's borders, and besides which action we want, if any, we can also configure a delay time so we don't get on our nerves because every time we slightly feather-brush any of the borders some action is insolently executed unintentionally.
Well, this feature should be available for the panel as well: If you want to take advantage of all your screen's size and don't need to have all the panel stuff at sight all the time you'll probably set your panel to hide/show automatically, especially on laptop screens. But there's no option to configure any delay, as soon as your ponter brushes the lower border, the panel abruptly emerges. It's really exasperating when you pass your mouse by the lower border because some interface requires it, for it has some buttons at its lower border, and suddenly the damn panel interrupts your workflow, forcing you to move away your mouse, and coming back for a second time to click, this time with surgeon's precision, what you really wanted to click without "wakeing up the monster".

I have seen this feature requested in several places since the times of KDE 4, at last, but I suppose no developer must be using autohide ergo devs probably aren't really aware of how annoying this defficiency is. So, please, devs, try it by youselves, just for a couple of days. Do us that favor and configure your panel(s) to autohide; when you reach the 13th or 14th time in a day you are bugged by this behavior and you are about to crash your computer against the wall, x-P, just relax and think if it would be too difficult to adapt the code that is already available for the window borders actions. It would be a huge usability improvement.

I think this is not a simple wish but a real usability deffect, that's why I'm marking it as a bug.

Cheers

Reproducible: Always

Steps to Reproduce:
1. Configure desktop panel(s) to autohide/show
2. Touch, even for a tenth of second, the lower border of your screen
3. Go take some tranquilizing infusion/pills/whatever (optional but recommendable)

Actual Results:
The panel shows without mercy, even if I didn't want it to show, and interrupt the real action I wanted to perform.

Expected Results:
To let the user set a delay so the panel doesn't emerge instantly.

Comment 1 David Edmundson 2016-08-18 23:28:44 UTC

The Plasma 5 implementation used to have this; and used the config option in kwin's screen edges settings for the delay.

Then it got changed back to be instant:
https://git.reviewboard.kde.org/r/123904/

If there's a valid reason, I'm all for closing this bug, but that review request makes it seem like it was just changed on a whim.

Comment 2 Martin Flöser 2016-08-19 06:12:34 UTC

> but that review request makes it seem like it was just changed on a whim.

Nah, there were complaints about it not triggering fast enough and that you have to push against the edge.

Which brings us down to: we have different and contradicting requirements here. We either make it trigger directly which makes users unhappy or we trigger with a pushback, which makes users unhappy.

Comment 3 eemantsal 2016-08-19 11:17:35 UTC

(In reply to Martin Gräßlin from comment #2)
> We either make it trigger directly which makes users unhappy or we
> trigger with a pushback, which makes users unhappy.

Well, in the screen borders System settings module the actions activation delay can be set to 0 miliseconds. That's what I'm asking for: an activation delay control tool that allows the user set as many miliseconds as they want, be it 250 ms for some or 0 for those who complained because the panel didn't trigger fast enough. In the mentioned KCM module there are two delay controls: activation and reactivation; in this case only one would be necessary, I think.
I think such a simple thing would make happy both "factions" of users.

Comment 4 eemantsal 2016-08-19 11:22:29 UTC

(In reply to eemantsal from comment #3)
Oh, and the best place to put said configuration tool wouldn't probably be System settings but the Panel preferences/More preferences thing, under the «Visibility» title. Excuse if I'm not giving the correct name; I don't have my desktop in engish and am translating on the fly.

Comment 5 Martin Flöser 2016-08-27 15:18:28 UTC

Having different activation delays configurable for screen edge actions like present windows and for auto-hiding panel is over configuration. Sorry that won't happen.

Given that it was a deliberate decision to always trigger the panel immediately I'm setting this bugreport to wontfix.

Comment 6 eemantsal 2016-08-28 17:37:51 UTC

Well, wasn't KDE that desktop that allowed to fine grain configure stuff, as opposite to Gnome's "users are idiots" mentality -Torvalds dixit-? Is your opinion just a personal one or is it consensuated with other developers? If most of the devs agree about that overconfiguration problem I suppose there's not much to discuss, but then what do you think of making panel use the same configuration of the screen borders actions? That'd be easier for everyone, right?: just a single checkbox to enable/disable delay, if the user enables it, then the delay time in the Present windows/Show desktop/etc configuration would be applied to the panel, no special configuration for it; if the user doesn't, everything behaves like now and the panel triggers immediately.
That wouldn't add an excessive amount of configuration options and would improve Plasma desktop's usability a lot for laptop users, don't you agree?

Comment 7 Martin Flöser 2016-08-29 09:31:25 UTC

> Well, wasn't KDE that desktop that allowed to fine grain configure stuff, as opposite to Gnome's "users are idiots" mentality -Torvalds dixit-?

And with that comment you just disqualified for any further discussion. Sorry on that level we don't discuss.

Reassigning away from KWin to not get any further comments.

Comment 8 eemantsal 2016-09-19 13:56:01 UTC

Oh, no, another one of those developers who are convinced that KDE is their property and shakes off a suggestion he's not interested in with a “sloppy” answer... "disqualifyied"? Where and who do you think you are, the teacher at the kindergarten? Please, stop playing roles and be sincere: «I'm not insterested at all in such a silly feature, and not going to lose a second with it. You, mortal users, just cope with my will as long as you are my dominions, KDE land».
Then you go and, without the slightest blushing, ask the users to collaborate in triaging bugs, suggesting ideas, donating money... Shameful.

Well, enjoy your insignificant “triumph” if that makes you feel happier. I just hope that if any other developer, less puerile, sees this, even if in years, perhaps will take it as seriously and respectfully as a suggestion that would clearly improve the usability a lot deserves.


Bye.


P.D: A reflexion in case some other “powerful” KDE members would read this: KDE seriously needs some mechanisms to control these "autocratic" developers, if we really want KDE to be a real community; if not, well, ok, but the stop advertising it as a “community” of developers and users.