Community
Participate
Working Groups
"mark as read" action in the task list removes selection. you have to hit "Down" to select something again before you can mark next task read.
I can not reproduce that. Are you using "Focus on Workweek" mode?
You are right. That is only for the "focused" mode, when read tasks are filtered out after "mark as read" action.
I use the "Mark as read and go to next unread task" (F8) to navigate in focused mode. You can also press F6 to go to the next unread task when no task is selected. I think the current behavior is correct since the task disappears from the task list and it is not clear to me what should be selected in that case.
(In reply to comment #3) > it is not clear to me what should be selected in that case. I'd say - the task that was shown next to the one filtered out. Though quite few places in Platform UI don't do that (i.e. dialogs that have add/remove actions, such as templates property pages)
Created attachment 89919 [details] preserve selection on clear This patch preserves the selection when the search text is cleared. I have committed the changes to CVS. Attaching in case this causes unforseen problems and we need to revert for 2.3.
Created attachment 89920 [details] mylyn/context/zip
Created attachment 89921 [details] select next item when marking task as read Attaching changes to DelayedRefreshJob in case we need to revert for 2.3.
The refresh job now attempt to select the next item if the selected elements disappear from the task list during a refresh. Please test this, e.g. by marking a task read (Alt+R) when in work week focused mode. We can revisit next week if this should go into the release or not.
(In reply to comment #8) > The refresh job now attempt to select the next item if the selected elements > disappear from the task list during a refresh. Please test this, e.g. by marking > a task read (Alt+R) when in work week focused mode. We can revisit next week if > this should go into the release or not. That could be related to additional refreshes introduced for bug 143577
Steffen: I'm not sure what you did and what status this patch is in, but I really like the way that selections are currently being handled in HEAD. Instead of disappearing when an item is not available, the selection goes to the next item, which is much more intuitive.
Yes, that is the change I made. The other change I made is that when you search and select something the view will retain the selection when you click clear. Marking as resolved. Please comment if you encounter any unexpected behavior.
I spotted a small issue few times fir this fix. In some cases, marking single or multiple tasks as read could significantly shrink number of nodes shown above current selection (e.g. when selected task appear multiple times as a deeply nested subtask). As a result, the next task you selecting could be outside of screen and it is not revealed. I don't know if there is a missing reveal() call or it is a glitch of the widget used to show tasks in task list.
The call is "treeViewer.setSelection(new TreeSelection(treePath), true)". I haven't been able to reproduce the reveal failing so far. Can you give a more specific example of the case where it fails?
Created attachment 90713 [details] mylyn/context/zip
No. Like I said, I've seen few times current selection was above the visible area, but I can't reproduce what previous selection or configuration of unread tasks caused that.
