Summary: | pager shows two active desktops | ||
---|---|---|---|
Product: | [Unmaintained] plasma4 | Reporter: | charly ghislain <charlyghislain> |
Component: | general | Assignee: | 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
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 |