As it is now, there is a problem when trying to trigger an action with the screen angle: the effect sometimes triggers on and off. How to reproduce: 0) Add some effect to the left-top angle, for example someting like showing all windows. 1) Move the mouse to the left-top angle, until the effect triggers on. Don't stop. 2) Continue moving the mouse left-top for a second or two. The effect triggers off. The mouse is somewhy moved back (down or right) 1px after the effect triggers (in step 1). It doesn't move back if there is no action associated with that angle. This is even more noticable with a touchpad. Possible solutions: 1) Do not move back the mouse 1 px, if there is an effect associated with the angle. 2) Actions for screen edges and angles should have several pixels threshold before triggering again. Add a threshold of about 5-10 px (probably, depending on DPI), so that the effect will first trigger as it is now, and will not trigger second time until the mouse is moved out of the threshold area. The problem with solution #2 is that such behaviour should depend on the type of the effect: it will work bad if the effect is «forbid launching screen locker».
The pushback is configurable: systemsettings -> workspace behavior -> screen edges -> Reactivation delay I think with that users are able to adjust the system to their specific needs for the input device. Unfortunately there are many different input devices which require different settings, there's not the one size fits all.
That looks like a work-around, not a proper solution. If the action is, for example "show dashboard", and a user _continues_ moving mouse for a second in the same direction — he clearly doesn't expect for the dashboard to disappear again. If user moves mouse back and then to the angle again — then yes. But as it is now, kwin doesn't distinguish guestures "move mouse away and then back to the angle" (which should trigger the event again, hiding the dashboard) and "continue moving mouse in the same direction" (which should, obviously, do nothing). Are you sure that this is ok?
> Are you sure that this is ok? our settings have to be sane for the most common usecases. That a user continues to move the mouse into one direction for a second after visual feedback has been given is quite clearly a cornercase. We expect a user to notice the change and stop to use the mouse movement. The screen edge is meant to be triggered actively by the user and is designed to easily deactivate an unexpected activation. We can expect that a user willingly triggering the edge will stop the movement, while a user who does not willingly trigger the edge needs a chance to quickly revert the action. Here it is quite clear that giving users the possibility to easily deactivate the action again is more important than the named cornercase. In fact if it were a problem we would have received quite some feedback about it in the last five years :-)
> That a user continues to move the mouse into one direction > for a second after visual > feedback has been given is quite clearly a cornercase. Not one second, it's set to 350ms by default. It's easily reachable with a touchpad. Look, here is a use-case: 1) The user wants to trigger the effect that is bound to left-top angle. 2) The user wants to move mouse to the left-top angle to trigger the effect. 3) The user doesn't bother where the pointer is now, he just moves his finger on the touchpad from right-bottom to left-top (till the end), knowing that that would surely move the pointer to left-top angle and expets the effect to trigger once. 4) The effect is triggered on and off. > Here it is quite clear that giving users the possibility to easily > deactivate > the action again is more important than the named cornercase. Moving the mouse back a little and to the angle again is quick enough. Ok, that was my opinion, sorry for the noise.
as I wrote in comment #1 there is not one setting which suits all hardware. We can either make it work good for touchpads or for mice.
(In reply to comment #5) > as I wrote in comment #1 there is not one setting which suits all hardware. > We can either make it work good for touchpads or for mice. Why won't several pixels threshold (as i decribed) suit? Or some other way to detect if the user moves mouse backwards? There still be a natural way to quickly disable the effect.
The pointer needs to be pushed back (the distance is configurable) in order to "measure" the activity in the corner (ie, the users will against the activation delay) You already pointed the weakness of the threshold approach and there're are also efforts to make the screen border activation more generic and likely even act as server for random clients. Using the timer is so far the most robust and generic solution and works but for the "sorry, but i couldn't stop moving my finger for a second" argument :-\ issue: kwriteconfig --file kwinrc --group Windows --key ElectricBorderPushbackPixels 0 qdbus org.kde.kwin /KWin reconfigure NOTICE: that from this time on there will be NO delay on the screen borders be possible
(In reply to comment #7) > Using the timer is so far the most robust and generic solution and works but > for the "sorry, but i couldn't stop moving my finger for a second" argument > :-\ Ok, sorry i bothered you with such a minor thing. It's probably better as it is now. > issue: > kwriteconfig --file kwinrc --group Windows --key > ElectricBorderPushbackPixels 0 > qdbus org.kde.kwin /KWin reconfigure > > NOTICE: that from this time on there will be NO delay on the screen borders > be possible That makes the behavoiur rather wierd. 0) Move mouse out of the sreen angle. 1) Move mouse to the screen angle, effect toggles on. 2) Move mouse out of the screen angle. 3) Move mouse to the screen angle, effect toggles off. 4) Move mouse out of the screen angle. 5) Move mouse to the screen angle, nothing happens. (??) 6) Continue from step 0. This doesn't depend on timings. It's perfectly repeatable, exatly one of each three actions is lost.
(In reply to comment #8) > That makes the behavoiur rather wierd. Indeed. While the setting is undocumented and unsupported that looks like a bug - i'll have a view tonight.
http://git.reviewboard.kde.org/r/104420/
Git commit 31dc2b01e29a8249f186625b3f1d6e0a0f9af0a2 by Thomas Lübking. Committed on 27/03/2012 at 00:40. Pushed by luebking into branch 'master'. fix some value inits for the no pushback case REVIEW: 104420 M +3 -0 kwin/screenedge.cpp http://commits.kde.org/kde-workspace/31dc2b01e29a8249f186625b3f1d6e0a0f9af0a2