Community
Participate
Working Groups
With the task list in scheduled presentation, resize so Incoming is near the bottom of the list. Place the mouse just to the right of the expansion arrow and click, and when Incoming expands, the activate button of the first incoming task will move so it is under the mouse and the task will be activated.
That's an interesting side effect. It looks like the mouseDown() event is fired after the expansion and auto scrolling happens. Shawn, do you have any thoughts on how we can detect this? Gtk does not seem to scroll lists on expansion. Leo, how is that on Mac?
Sorry, I can't reproduce this. Is the expectation that the task list scrolls up when the container is expanded? Because that doesn't happen on the Mac, so this won't be an issue.
(In reply to comment #2) > Sorry, I can't reproduce this. Is the expectation that the task list scrolls up > when the container is expanded? Because that doesn't happen on the Mac, so this > won't be an issue. That's what happens for me, but I'm not sure what determines when it happens. It seems to be only when the thing being expanded would expand to below the bottom of the list.
Created attachment 183496 [details] fix using timing This may not be the "right" solution but it seems to work nicely. I did this because this bug was still bothering me quite a bit even though I was aware of it and tried to avoid clicking in places that would trigger it. I think it's somewhat important to fix this bug (in this way or another) because the first n times I encountered it, where n is quite large, I didn't know what was going on and just had the impression that sometimes Mylyn randomly (de)activates a task. It could create the impression (especially for new users) that Mylyn is "flakey." And if you don't quite understand the concept of task context yet, it could be even worse having files randomly opening and closing when you just expand things in the task list.
Created attachment 183497 [details] mylyn/context/zip
So the mouse event has no indication that the tree was previously expanded? Would it work to add an expansion listener instead of hacking the content provider? That would be less brittle. Would be nice if we could also tackle bug 186667 with the fix.
Created attachment 183610 [details] clipboard.txt Yes, it's better to use an expansion listener, I didn't think of that.
(In reply to comment #7) > Yes, it's better to use an expansion listener, I didn't think of that. If you get a chance it would be great if you tried that. I can't recall but we might have already done that without getting it work because expansion events were fired after mouse event. In that case we'll go with the proposed approach.
I did try it and it seems to work. I submitted an updated patch.
Actually, I enountered the bug again just now, but I'm not 100% sure I had restarted since applying the patch. After restarting with the patch applied it works again. The event order may be random so I would not commit this patch yet. I'll keep running with it and let you know whether I have problems.
(In reply to comment #10) > Actually, I enountered the bug again just now, but I'm not 100% sure I had > restarted since applying the patch. After restarting with the patch applied it > works again. The event order may be random so I would not commit this patch yet. > I'll keep running with it and let you know whether I have problems. Now I understand why I encountered the bug even with the patch applied: it also happens when you __collapse__ a folder at the bottom of the task list, causing tasks above it to move down, though that seems to be a much less frequent occurrence. Here's an updated patch that listens for Collapse as well as Expand. I believe this is a fix.
Created attachment 184481 [details] clipboard.txt
The patch does not apply cleanly against head. Sam, can you please cut it again?
Created attachment 184878 [details] patch_again.txt Sorry about that Steffen. This one applies against head.
Awesome! That fixes bug 186667 on Linux as well. I have committed the patch. Leo, can you check if the fix also works on Mac?
It's fine on the Mac
Great! Thanks for testing. I'm marking this as resolved then.
Created attachment 192160 [details] make sure activation works Steffen, the fix for this bug created a new bug where you can no longer click the button to activate tasks after travelling backwards in time. This patch fixes that.
Reopening until this bug is fixed.
I have opened bug 341565 to track the fix as the change tracked on this bug has already been released. Please attach the patch to the new bug.
