Version: (using KDE 4.0.0) Installed from: Unspecified Linux OS: Linux Hi, Pager shows active desktop with white borders. You can change desktop by left-clicking on his button, but it has small issues when the mouse button is released elsewhere: 1: When you release the button outside of the pager (as you were trying to drag the desktop button on the destop), the destop button from wich you started the manipulation is marked as active, along the really active desktop. (go to destop 3, click on the 2nd desktop button, release the mouse button on the desktop: desktop 2 & 3 are marked as active) 2: When you release the mouse button on another desktop button, that last one is made active. It might be more natural to activate the one on wich you started the manip.
I can reproduce both issues and will try to fix them. However, if you release the mouse on another desktop button, I think it might be a better behavior to just do nothing. If the user moves the mouse away from the desktop he just began to click on, the reason is probably that he clicked accidentally. I agree that the current behavior, switching to the desktop the mouse is currently on, is unnatural, but switching to the one on which you started the manip also seems unnatural to me. So ignoring the action is probably the best way. The old KDE 3 pager does the same. If you don't agree with that change, please object here.
Created attachment 23145 [details] Fix for both issues, uses hoverLeaveEvent Okay, I have a patch that fixes the bug and also adds some temporary debug messages. The problem is that the applet does not always get mouseReleaseEvents. The pager relies on getting these events to determine when a drag is finished. If you click on a pager in the panel but release the mouse button on the desktop or on another window, you don't get a mouseReleaseEvent. What I found strange is that this never happened when the pager was on the desktop. As a workaround, I've tested different events and it looks like only the hoverLeaveEvent works reliably. Now I use this event additionally to end drags which seems to work well. The only drawback is that it could end a drag too soon when the user accidentally moves the mouse up and leaves the panel. I'm also not happy with this workaround. That's why I will wait until aseigo is back who hopefully has some idea why the events don't work reliably before committing this to trunk and 4.0.
aside from some messiness in the patch, it generally looks ok. it would be best if the state was restored on hoverEnter if there isn't a drag, of course. but this is an improvement. i also have a patch here to the pager that prevents it from cycling through all the open windows on each mouse movement (!) i'll commit that after you clean up and commit your patch, Daniel, so as to avoid possible conflicts.
Okay, I will commit tomorrow. Thanks for your help! What messiness do you mean exactly, apart from the debug stuff, which I'll remove before commiting?
I fixed the bug in revision 765778, see http://websvn.kde.org/?view=rev&revision=765778