Select a task after adding it via quick add

[Christoph Haas]

I would like the tasks window to open after quick-adding a new task. Even though quick-adding is a great feature I often feel that I should add some text to help me understand later what I meant to do exactly.

As that could possibly annoy users it could be made optional by a preferences option.

[Bryce Harrington (bryce)]

That's not a bad idea. It's a feature I'd definitely use, as I tend to be kinda verbose. ;-)

However, I think I'd get annoyed if it *always* popped up the taskeditor on entry, since I usually only need to enter more text sometimes... half the time or less I'd guess.

What would you think if instead, it was just a keyboard shortcut? E.g. use 'ctrl-enter' instead of just 'enter' to cause it to pop up? Then it'd be there for everyone by default, but wouldn't "get in the way". People like us with workflows that want to elaborate can use the shortcut, but it won't impact those who tend towards brevity.

One reason I think preference options should be avoided when possible is that it makes testing a lot harder. E.g., imagine if you and I were the only gtg users who prefer it this way; then no one but us would have it turned on, and so no one else is really testing our particular configuration. So bugs could show up that only you and I can reproduce, and it'd be hard to figure out, "Oh, it's because we have 'auto-launch-task-editor' enabled." Another reason to avoid preference options is because they tend to accumulate, to the point that the preferences panel gets overwhelming with way too many choices.

[Bryce Harrington (bryce)]

Oh, one further comment. I've noticed that when a new task is entered, gtg does not scroll the window to where it entered the task, nor even selects it. I don't know if that is intended behavior or bug, but it seems to me to not match what I expect.

If it *did* behave this way, then after entering a new task, I could just hit 'enter' again to load the task editor. So that would make a simple workflow - "foo foo foo"<enter><enter> @bar<enter>"Foo is a bar blah blah blah".

What do you think of that? If we fix that one (bug? mis-feature?), then this improves the workflow such that we don't need to go so far as to open the task editor magically.

Bertrand, would like to get your feedback on this idea too.

[Luca Invernizzi (invernizzi)]

I was thinking about ctrl+enter too. The only problem is that is not easily
discoverable.

On Aug 8, 2010 10:50 PM, "Bryce Harrington" <email address hidden>
wrote:

That's not a bad idea. It's a feature I'd definitely use, as I tend to
be kinda verbose. ;-)

However, I think I'd get annoyed if it *always* popped up the taskeditor
on entry, since I usually only need to enter more text sometimes... half
the time or less I'd guess.

What would you think if instead, it was just a keyboard shortcut? E.g.
use 'ctrl-enter' instead of just 'enter' to cause it to pop up? Then
it'd be there for everyone by default, but wouldn't "get in the way".
People like us with workflows that want to elaborate can use the
shortcut, but it won't impact those who tend towards brevity.

One reason I think preference options should be avoided when possible is
that it makes testing a lot harder. E.g., imagine if you and I were the
only gtg users who prefer it this way; then no one but us would have it
turned on, and so no one else is really testing our particular
configuration. So bugs could show up that only you and I can reproduce,
and it'd be hard to figure out, "Oh, it's because we have 'auto-launch-
task-editor' enabled." Another reason to avoid preference options is
because they tend to accumulate, to the point that the preferences panel
gets overwhelming with way too many choices.

--
Open task's window after creating a task with quick-add
https://bugs.launchpad.net/bugs/615029
...

[Luca Invernizzi (invernizzi)]

I remember to have written the support for scroll-and-select, so it should
be a quick fix. This is better than the shortcut solution.

On Aug 8, 2010 10:57 PM, "Luca Invernizzi" <email address hidden> wrote:

I was thinking about ctrl+enter too. The only problem is that is not easily
discoverable.

>
> On Aug 8, 2010 10:50 PM, "Bryce Harrington" <email address hidden>
wrote:
>
> That's not a...

>
>
> --
> Open task's window after creating a task with quick-add
> https://bugs.launchpad.net/bug...
...

[Christoph Haas (chaas)]

Am 08.08.2010 22:46, schrieb Bryce Harrington:
> Oh, one further comment. I've noticed that when a new task is entered,
> gtg does not scroll the window to where it entered the task, nor even
> selects it. I don't know if that is intended behavior or bug, but it
> seems to me to not match what I expect.
>
> If it *did* behave this way, then after entering a new task, I could
> just hit 'enter' again to load the task editor. So that would make a
> simple workflow - "foo foo foo"<enter><enter> @bar<enter>"Foo is a bar
> blah blah blah".

Now that's a great idea.

- Allows to add details to a task only if wanted.
- Intuitive because the new task gets scrolled to and highlighted.
- Spares searching for the newly created tag.

+1 from me!

 Christoph

[Luca Invernizzi (invernizzi)]

Fixed, but we might still have to account for another problem.
From my commit message:
"""
After quick-adding a task, it gets selected in the treeview.
  The focus is passed to the treeview, so that the user can press "enter" to open
  the task.
  This could be annoying when adding several tasks, since the focus is stolen.
  Two solutions for that:
   - we avoid moving the focus
   - we add a keyboard shortcut for the quick add. Probably it's already there, I
   don't know.
"""

[Lionel Dricot (ploum-deactivatedaccount)]

Luca, 2 remarks >

1. I believe that it doesn't make real sense to pass the treemodel and do all the work in browser.py. Instead, I would have implemented a "select_node" in liblarch and use it in the browser. What do you think ?

2. A very common usecase (according to user's feedback) is to type many tasks in a row in the quickadd filter. Your commit breaks this usecase (and a shortcut key would not be enough for many I guess).

I would then suggest the following behaviour :

- The focus stay in the quickadd after the user hit enter. (the task is selected to give the user a visual feedback but the focus is still in the quickadd)
- If the user hit enter with an empty quickadd field, the currently selected task in the active treeview is opened. If no task is selected, nothing is done (current behaviour).
- When the user close the task (or move the focus to the main window), the focus is still in the quickadd field.

It would allow the following scenario :
- task1 <enter> task2 <enter> task3 <enter><enter> <alt+f4> task4<enter>

which will result in creating task1, task2, task3, opening task3, closing task3, creating task4. All without leaving the keyboard and without any strange shortcut (given that alt+f4 is quite common)

[Luca Invernizzi (invernizzi)]

2. is a nice idea to solve the problem, and it works well (it's in trunk now).
As for 1., I'm all for encapsulation and keeping things separate, but in this particular case I haven't found a simple way to put that code in liblarch, as it's very bounded with the browser.
The "issue" stands in the fact that the requester creates-the-task-and-loads-it-in-the-tree in one step, making it impossible to say:
"ehi, I want you to wait for tid X and select it when it is loaded", since I should do that call before adding it to the tree, but I would also need the tid. Maybe the task_factory of the datastore should be exposed.
So, that seems to require a bit of refactoring, but now it's bedtime. Maybe I'm not seeing an easy way to do that, ideas are welcome.

[Luca Invernizzi (invernizzi)]

marking as Fix Committed as the refactoring is not going to change functionality, and that seems ok.