Version: unknown (using 4.2.4 (KDE 4.2.4) "release 2", KDE:42 / openSUSE_11.1) Compiler: gcc OS: Linux (x86_64) release 2.6.27.23-0.1-default When setting "Present windows - Current desktop" as an action for the top left corner of the desktop, it seems to react only when the mouse is exactly at coordinate 0,0 of the desktop. However, when I move the mouse cursor close (i.e. 2-3 pixels away) to the corner, the cursor jumps away from the corner by a few pixels, like there was a force pushing it away. I don't know why this is happening but it is thus almost impossible to trigger the "present windows" effect by just flicking the mouse in the top left corner. I always have to move the mouse into the corner several times until it happens to hit 0,0. There would be two solutions to this issue: Either fix the mouse cursor not being pushed away from the corner or make the effect trigger not only react to coordinate 0,0 but to the surrounding pixels as well.
*** This bug has been marked as a duplicate of bug 174260 ***
Martin, the fix for bug 174260 only fixed the activation delay. But this report is about the size of the activation "region" (it is a single pixel for the corners currently). Maybe there is another duplicate, but this bug is definitely not fixed.
Hmm the OP offers two possible solutions and the first one is fixed. When setting the activation delay to 0 the mouse is not pushed away. So I think the problem is fixed, isn't it?
Just to clarify: I am not talking about any delay. What I am saying is that the mouse cursor simply does not properly reach the corner. Is this fixed? If so, only in KDE 4.3?
Nevertheless this is a duplicate of bug 174260. If the solution mentioned in 174260 is not appropriate that one should be reopened. *** This bug has been marked as a duplicate of bug 174260 ***
Not a duplicate of bug 174260, but it is one of bug 196541. *** This bug has been marked as a duplicate of bug 196541 ***
I am still not convinced these are the same issues. Sure, growing the trigger-area is a possibility as I wrote above, but the more I think about it, it is just a workaround for a bug that is clearly there but has neither been addressed nor been mentioned in the other reports. The issue is that the mouse cursor does not move in the same direction that I move my mouse in. Let's assume the following situation: The mouse cursor is on the absolute left edge of my screen (0, y). I start to move my mouse in the 11 o'clock direction so it stays on the left edge but approaches the top-left corner (0, 0). Now, before it reaches (0, 0), roughly at (0, 1) or (0, 2), the mouse cursor will start to jitter and jump between these coordinates and (1, 0) or (2, 0). For the majority of tries, it will however not reach (0, 0) at all, even though I am continuing to move my mouse towards that position. In other words, this issue is probably not even related to the "present windows" option at all, other than this is how I discovered it. Perhaps a better title for the bug report should be "Mouse cursor unable to reach (0, 0)".
just to note: it's not a bug it's a feature. It is intended that the mouse is pushed back to prevent accidentially activating of the corner. So you have to push the mouse into the corner to trigger the activation. That is what bug #174260 is about: "Option to disable active corner "push"" So now to the implementation part: when as mentioned in bug #174260 comment #2 the delay is set to 0 the push back is not activated and yes that belongs together. The delay time defines how long you have to push your mouse into the corner. Setting it to 0 there will be no push back. To me that solves your problem. If it doesn't for you please tell me what should be changed. Adding another option does not make sense as we already have such an option. Removing the functionality would be bad as it would cause accidentially activation of effects. Especially when you have an effect in right upper corner where there is often the close button of maximized windows. I hope I could explain a little bit.
Martin, you are forgetting us tablet users :) Please make the edge region sizes larger (or configurable) like visualized on the screen shot in one of the duplicates, especially for the corners. There should be something like "(x==0 && y<5 || y==0 && x<5)" for the top-left corner.
(In reply to comment #9) > Martin, you are forgetting us tablet users :) Please make the edge region sizes > larger (or configurable) like visualized on the screen shot in one of the > duplicates, especially for the corners. Configurable size of screen edges is bug #196541 - which is in my opinion unrelated to this bug. It's one of those things which would be nice to have - for tablet users I think clickable edges would probably the best. But that's not a topic for this bug report ;-)
Ah, I forgot about bug 196541. Yes, it is probably a duplicate. And btw, edges do not need to be clickable, real (Wacom) tablets support mouse hover. But it is a bit hard to get them exactly at position (0,0) and being of "absolute" nature, it does not make sense to artifically change mouse position.
Re comment #8: Ok, that explains it, thanks. However I find the implementation a bit weird. Why are you modifying the mouse cursor position instead of just delaying the event until the time threshold has been surpassed? If the mouse cursor had reached 0,0 but simply triggered the effect with a delay, I would not have filed this bug as it would have been clear what is going on. You should probably think about changing the implementation to reflect this.
(In reply to comment #12) > If the mouse cursor had reached 0,0 but simply triggered the effect with a > delay I disagree. We have to ask ourself what we actual want to do. If I want to trigger an action I will actively move my mouse into the corner, moving the mouse a little bit further is no problem when you want to trigger the action (I know touchscreens are another topic). But when it is just a delay you might trigger an effect without wanting to. For example: right upper corner - you want to close a window. To me it happens regularily that I move my mouse to the corner and stop to rethink if I realy want to close the window. In that case a delay would accidentially trigger the effect. The same is true for all other corners where you have control elements. Kickoff button is on left bottom, task applet is on bottom, etc. In all that cases we cannot expect that the user wants to trigger the effect. In my opinion the current way is the right way to go. Prevent accidential triggers. Btw I did not come up with this solution - not that you think I just want to defend my code ;-)
changing to wishlist and I probably will add a configuration option for how many pixels the mouse should be pushed back.
*** Bug 203655 has been marked as a duplicate of this bug. ***
SVN commit 1021306 by graesslin: Adding a new option to disable the cursor pushback for active screen edges. I haven't added it to the UI as the screen edges kcm is already a little bit cluttered with complicated options. So if you want to disable the pushback add option "ElectricBorderPushbackPixels" to section [Windows]. FEATURE: 198225 M +1 -0 options.cpp M +6 -0 options.h M +6 -1 workspace.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1021306