Community
Participate
Working Groups
Currently, when you click on "Open" action from the task list it will run synchronize on that issue first and only then open the editor. The problem is that synchronize takes quite long time (20..30 seconds). So, it would be much better user experience if editor would be opened immediately, and bugzilla page stays empty while synchronizing.
Curretly tasks are opened immediately if there is local task data (has been opened/synced in past). If your offline reporst was lost the sync would take place first then the task would open, otherwise this should be working. Is there a condition I've overlooked?
I was browsing trough query hits. Those have no task data and I can't synchronize them up front without loosing "incoming" marker.
Yes, hits are a problem in that respect. We don't have all the data to give them a task data object up front. I think we're stuck with this unless we get the complete bug report for each hit which would be too expensive. I'm not sure opening with a blank bug editor would be all that intuitive. At least there is the syncing (italic) of the task name to indicate that some work is ongoing followed by opening of the editors.
I'd prefer to have an option to fetch all issue data up front (it is still being fetched as I open/browse those issues). I think it is much better to open editor immediately and show progress bar in the bugzilla tab while it is loading. So, user won't have editors jumping out of nowhere after significant delay...
I see your point, renaming to reflect this idea. A progress indicator of some sort in the tab/page would be nice....
Note from my comments on bug 168432 that we don't yet have a clear guideline of whether the spinner should be on the form or on the editor tab. Also, here is what I would like to see for 2.0: 1) Open task editor: no background load, open is instant or close to instant since we are not going over the network. 2) Submit changes to server: editor stays open and shows progress indication when reloading input 3) Stale editor: reloads input in background when synch happens, and shows message in header to indicate to the user that the input has been re-loaded since their last viewing. The "incoming" indicator doesn't go away from the Task List until the editor has had focus and shown this message.
(In reply to comment #6) > 1) Open task editor: no background load, open is instant or close to instant > since we are not going over the network. How about opening editor if there is no data? I believe think it should still instantly open a stub editor. > 3) Stale editor: reloads input in background when synch happens, and shows > message in header to indicate to the user that the input has been re-loaded > since their last viewing. The "incoming" indicator doesn't go away from the > Task List until the editor has had focus and shown this message. This is the most troblesome one. I think it is ok to remove incoming indicator as you suggesting, but then task should stay visible in the task list until editor is closed.
(In reply to comment #7) > How about opening editor if there is no data? I believe think it should still instantly open a stub editor. I agree that this is better than locking up the workbench. > This is the most troblesome one. I think it is ok to remove incoming indicator > as you suggesting, but then task should stay visible in the task list until > editor is closed. Yes, this one will be tricky, and we should keep the "Stale Editor" dialog until we're sure that what we come up doesn't result in people accidentally missing incoming changes (very high cost).
(In reply to comment #8) > > How about opening editor if there is no data? I believe think it should still instantly open a stub editor. > I agree that this is better than locking up the workbench. It is not about locking workbench. Right now if task data takes long time to fetch you'll see that editor jumping out of nowhere when you already forgot about it... > > This is the most troblesome one. I think it is ok to remove incoming indicator > > as you suggesting, but then task should stay visible in the task list until > > editor is closed. > > Yes, this one will be tricky, and we should keep the "Stale Editor" dialog > until we're sure that what we come up doesn't result in people accidentally > missing incoming changes (very high cost). I am not arguing the stale editor dialog. Though I'd prefer if we had some floating panel on the editor instead (similar to the search and warning panels in FireFox). also note that "stale editor" dialog does not have a cancel option.
Steffen, what are your thoughts on this in terms of the new editor architecture?
This shouldn't be too hard to implement in AbstractTaskEditorPage but I don't think it's the most pressing usability problem. Let's take a look at it when we have completed the editor refactoring. We should be able to add it later on.
*** Bug 220078 has been marked as a duplicate of this bug. ***
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
