Set the panel to auto-hide, slam your mouse towards the edge and a blue glow will appear. However, the panel will not appear, only the blue glow. Additional mouse movement in the edge direction is needed for the panel to appear, which gets a bit annoying (actually a lot after longer usage). Moving the mouse very slowly towards the edge makes the panel show up correctly, moving faster than some threshold makes only the blue glow appear. Might also be some KWin feature, so adding Martin to CC.
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