Community
Participate
Working Groups
Currently "create local task" creates task in the Task List view and leave focus on newly created task. It should activate editor and have focus in the desctiption field in the editor.
It does this so that the task can be renamed in the list. The other option is to highlight the text in the editor. I want to ensure that making a new task is as easy as hitting Ins and then typing it's name. I have a slight prefernece for the focus being in the list. Rob what do you prefer? Related to this, I think that therre needs to be a default reminder set for a newly created task, because otherwise it doesn't appear with the Apply Mylar filter on. I would personally like that default being "tomorrow". Thoughts?
(In reply to comment #1) > It does this so that the task can be renamed in the list. The other option is > to highlight the text in the editor. I want to ensure that making a new task > is as easy as hitting Ins and then typing it's name. I have a slight > prefernece for the focus being in the list. Rob what do you prefer? I thought we already discussed that task should not appear in the list until you save editor... So, I think it would really make sense to select text in the editor. Then if you close editor confirming not to save if there are modifications, task won't be created in the list. Besides, it is completely weird right now. When you hit Ins, editor is activated, but focus is staying in the view.
I personally like the currnet behaviour of focusing on the title field in the task list, and perhaps if the editor didn't open automatically this behaviour would be okay. However, since the new bug's editor is opened automatically the users attention is naturally drawn to it. If the task editor is going to be automatically opened, focus should probably fall on the description field as Eugene suggests. I agree with your point about reminders being set and 'tomorrow' does seem reasonable.
(In reply to comment #3) > I personally like the currnet behaviour of focusing on the title field in the > task list, and perhaps if the editor didn't open automatically this behaviour > would be okay. However, since the new bug's editor is opened automatically the > users attention is naturally drawn to it. If the task editor is going to be > automatically opened, focus should probably fall on the description field as > Eugene suggests. I can suggest to implement following: -- Ins for "quick new task" without opening editor. -- Ctrl-Ins opening new editor and set focus to the editor > I agree with your point about reminders being set and 'tomorrow' does seem > reasonable. Can we have property in workbench preferences? Eg "add default reminder" check box and then choose number of days or hours when to remind (see team sync shedulle settings).
Rob, you doing this for 0.6? If not set Milestone to 0.7.
I'm going to push to 0.7.
After some consideration I'm leaning towards insert or new task creating the 'task' in the task list where you enter the task name and hit enter (no opening of the editor). I think this might make more sense especially for new users. More often than not when creating new local tasks I don't require viewing the entire editor, just the task name is enough. If I need the extra fields, I'll open the task. Thoughts?
Not exactly related but in current implementation, when Task List is in Quick view mode there is someweird flickering happening on creating new local task. PS: btw, new name "shared task" for repository tasks is kind of weird...
I was experimenting while writing the article. While the name "Shared Task" has the benefit of being about the intention and not the implemention, it is a bit too wierd so I've flipped it back to Repository Task.
Regarding comment #7, I would find it much more convenient to have the task just appear in the task list. I often end up creating a bunch of tasks at once (i.e., when reading email) and its a pain to close down all of the editors that end up open. At best, I will typically set an end date or maybe put a note on, but double-clicking would be fine for this. One possible interaction might be that once the task is created it might be hard to find it (depending on filters, apply mylar button on, etc.).
Thanks for your input on this Gail. You raise a good point regarding visibility. At least new tasks are scheduled for today so should appear when mylar is applied to tasklist. Lets try it and see how it goes. I've committed the change so that the new task editor no longer opens automatically.
All local tasks get scheduled for today when created, hence they should appear in the list when in Apply Mylar mode. If we auto-activate on open (bug 125936), the task will also become bold and get focus. This would also have the effect of not bloating the number of task editors when creating several tasks...
Folks, it seems to me that few last comments are unrelated to the issue I raised. Mylar should either don't open new task editor for local tasks and allow their description to be edit right in Task List, or if it does open editor, then editor should get focus and description should be edited in the editor.
Makes sense to me, and yes, we diverged from the original topic. I'm inclined to do the latter thing Eugene suggests. The only problem is that people always get confused that editing the Description field because it doesn't update the Task List view (until they hit save, which they forget to do), whereas updating the view updates the editor. This is because we follow the Eclipse view vs. editor save lifecycle difference. So maybe the right thing to do is change immediately (as happens with the outline), and the fall back to previous value if a save wasn't done.
(In reply to comment #14) Mik, that is exactly why I suggested to not add task to the Task List before editor is saved. If you not open editor and want to edit local task in-place, then you could discard that entry from Task Lisk if user hit Esc and only save and add it if user hit Enter.
Any update for this? Also note that new repository task editor should also get focus on summary entry field.
Actually, I just resolved bug#159220 yesterday. Haven't look into this one.
Right. I saw that, but then found this one, which is long annoyance...
As per conference call I'll update so that focus goes to description field in editor (and will rename description field to summary).
Update: Description renamed to summary in editor. Rename action on new task in tasklist no longer activated up on new task create. For some reason focus is being drawn back to the tasklist after the editor is opened and I couldn't track the source on initial investigation. Will try to resolve this along with bug#159223 as this is likely related to tasklist focus/refresh.
Rob: that focus loss could be coming from the fact that the selection is set on the Task List when the editor is brought to the top. But while the selection should be going to the Task List, the focus shouldn't. I think that code is in MylarTaskEditor.
(In reply to comment #21) > Rob: that focus loss could be coming from the fact that the selection is set on > the Task List when the editor is brought to the top. But while the selection > should be going to the Task List, the focus shouldn't. I think that code is in > MylarTaskEditor. Shouldn't be task list listening on platform selection service and editor contribute selection there?
(In reply to comment #22) > Shouldn't be task list listening on platform selection service and editor > contribute selection there? > Yes, this is the "correct" way. And if possible, be able to turn off this behavior :) I opened bug#165380 for this autoselection stuff.
Update: selection now goes to summary field. Still need to refactor as per comment#22...
Done.
