Bug 156004

Summary: pager shows two active desktops
Product: [Unmaintained] plasma4 Reporter: charly ghislain <charlyghislain>
Component: generalAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: laidig
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Fix for both issues, uses hoverLeaveEvent

Description charly ghislain 2008-01-17 15:55:05 UTC
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.
Comment 1 Daniel Laidig 2008-01-19 20:23:07 UTC
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.
Comment 2 Daniel Laidig 2008-01-19 22:39:11 UTC
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.
Comment 3 Aaron J. Seigo 2008-01-23 21:53:04 UTC
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.
Comment 4 Daniel Laidig 2008-01-23 22:04:45 UTC
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?
Comment 5 Daniel Laidig 2008-01-24 19:40:13 UTC
I fixed the bug in revision 765778, see http://websvn.kde.org/?view=rev&revision=765778