Current task unselected in tasklit when closing a task editor

[Alexandre COLLIGNON]

Test plan :

- Open a task of our tasklist ;
- Check that the task is selected in the tasklist ;
- Close the task editor ;
- Check that the task is not selected anymore.

[Chris Johnston (cjohnston)]

I disagree with this bug report. The only options that you have from keyboard shortcuts are:

Mark as Done
Dismiss
Delete

Your only other option would be to scroll up or down with the keyboard. I doubt very seriously that many people will close the editor to mark it as done, or dismiss/delete. Because of this, I don't believe that a task should remain selected after the editor is closed.

I'm curious what your reasoning is for leaving it selected?

[Luca Invernizzi (invernizzi)]

pros:
 - user expects that a task remain selected. As Chris said, it's useful if someone uses the keyboard to navigate the tasks

cons:
- cleaner interface?

I introduced that behavior when writing support for multiple selection but, after thinking about it, I'm not for it now (it was useful to test different aspects of multiple selection, though).

[Bryce Harrington (bryce)]

I do think having the task remain selected matches user expectations.

An example workflow where this significantly aids usability could be:

1. Add a new task
2. Open task in task editor. Add 5 new subtasks
3. Close task editor (Esc)
4. With the task selected, highlight the next 5 lines (the 5 new subtasks)
5. Defer the tasks until tomorrow (<ctrl>1)

[Luca Invernizzi (invernizzi)]

This bug is triggered in GTG/taskbrowser/browser.py
by the last two lines of this snippet:

    def on_task_modified(self, sender, tid):
        if self.logger:
            self.logger.debug("Modify task with ID: %s" % tid)
        self.task_tree_model.update_task(tid)
        if self.task_tree_model.remove_task(tid):
            self.task_tree_model.add_task(tid)

So it seems easy to understand why: all the tasks are removed and re-added from the tree model. Question: why?
Lionel is the expert on the refresh stuff, so I'll wait for him.

[Alexandre COLLIGNON (alexandre-collignon)]

Chris,

I report this bug because it is annoying to lose the current selected task when you are doing your weekly review (according to the GTG method). This process consists of checking each task to see if you can dismiss / close / defer it. If the current task doesn't remain selected, you have to read the entire list to find the next task to check.

[Bertrand Rousseau (bertrand-rousseau)]

I guess we should leave the current selected task as selected, just because that's the way we left the window. If you come abck after, and the selection changed, then it feels like someone messed with your stuff, that's not enjoyable. Btw, this bug is more than likely introduce by some the way we handle our model. Lionel is working on refactoring a bit our data structure, so that we have more coherent ones. The next step would probably be to behave correctly in regard to our GTKTreeModels, since when you using them right, these kind of behavior doesn't show.

[Lionel Dricot (ploum-deactivatedaccount)]

I've fixed that bug a while ago.