Bug 339203

This is configurable in KWin. KWin doesn't trigger screen edges directly, but requires a strong push.

And I guess there's one setting to rule all the corners/edges? I think it makes kinda sense for the "expose" corner, but the edges where panels are are quite annoying. 

Any chance to lowering the defaults? ;) (also because I didn't even know there is such setting, now imagine the ordinary users...)

> And I guess there's one setting to rule all the corners/edges?

yes

> I think it
> makes kinda sense for the "expose" corner, but the edges where panels are
> are quite annoying.

I would find it annoying if just moving the mouse shows the panel. So there is 
no general one way to make everybody happy. Please also keep in mind that 
there are input devices which are not as precise as a mouse - e.g. a touchpad 
or the thinkpad ball.

> 
> Any chance to lowering the defaults? ;) (also because I didn't even know
> there is such setting, now imagine the ordinary users...)

screen edges KCM - where else should it be? And no, we won't tweak the 
setting, it's always creating problems - especially with the not so precise 
devices. There's a reason why we introduced it.

> KWin doesn't trigger screen edges directly, but requires a strong push.

Hopefully this works with absolute devices, such as styli.

> > KWin doesn't trigger screen edges directly, but requires a strong push.
> 
> Hopefully this works with absolute devices, such as styli.

screen edges cannot reasonably be triggered with absolute devices and it 
hardly makes sense. Given Fitts's law hitting a screen edge with a mouse is 
very easy as the target size is infinity. With an absolute device the target 
area is reduced to one pixel which is extremely difficult to hit given Fitts's 
law.

Anyway it's configurable. We cannot detect what kind of device is used, if we 
knew we could do something about it. But as for us (at least on X) everything 
is a mouse, we cannot know what is used.

Moving to kwin as they handle the edges (though this looks closable to me)

on kwin side that is a worksforme as there is a configurable option for it.

the OP actually reads (slow approach works, fast doesn't) like bug #338593 to me - there might be another issue.

about absolute input devices:
this should "still" work (with zero timeout) and fitt should not be a problem either. styli can usually be moved "like a mouse" (w/o implied button down) and the common touch approach is to approach from outside.

One thing from my side: I intend to add unit tests to ScreenEdges. This should 
help identify potential issues and make it easier to change the code. Though 
adding tests to it, might be very tricky.

Small update: I just pushed an initial auto-test for KWin's screen edge handling [1]. The test does not yet cover the Client show handling, but it should be relatively easy to get it under coverage.

What I noticed during writing the code is:
* infrastructure supports special cases without a pushback
* client activation could be moved to such a special case without breaking existing functionality

My suggestion is: raise this on plasma-devel to find a conclusion on how it should behave (or whether another config option is required) and let's get the code under coverage and change depending on how the outcome of the discussion is. (I'll probably be not able to finish the test before vacations and XDC due to me having a slight migraine today. I want to do some work tomorrow morning, but don't know how much time I'll have).

[1] http://commits.kde.org/kwin/883445d5e8713b7aeb15b9227e55ed0828995eff

This was fixed with c4140d6f4e5cd953023f2c078088d20a553ab875