Community
Participate
Working Groups
Adding a new comment in the editor uses a modal dialog and is blocking the user while submitting the comment. This should be done in the background so I can continue working (and closing the compare editor).
Same for publish comments dialog, that should happend in the background too without blocking the user.
Yes, the model should have proper offline support to enable submitting of changes in the background.
Note that we addressed the immediate issue "blocking the user while submitting the comment" in bug 321270 and bug 344108. So I just wanted to clarify what this bug is about now. Are we talking about writing the task-data/model -> Gerrit in background, allowing changes to be made in review editor without attempting to make live changes in the Gerrit model while off-line, or what?
(In reply to comment #3) > Note that we addressed the immediate issue "blocking the user while submitting > the comment" in bug 321270 and bug 344108. So I just wanted to clarify what this > bug is about now. I'm not aware that the workflow for inline commenting has changed. It still uses modal dialog as far as I know. > Are we talking about writing the task-data/model -> Gerrit in > background, allowing changes to be made in review editor without attempting to > make live changes in the Gerrit model while off-line, or what? Yes. A first step in that direction would be submit changes in the background instead of blocking the user but that to some degree requires caching of the data, e.g. to handle resubmission in case of errors.
(In reply to comment #4) > (In reply to comment #3) > > Note that we addressed the immediate issue "blocking the user while submitting > > the comment" in bug 321270 and bug 344108. So I just wanted to clarify what > this > > bug is about now. > > I'm not aware that the workflow for inline commenting has changed. It still uses > modal dialog as far as I know. Right, I missed the point of the "in the editor" part. That clarifies everything. I was thinking "in the *review* editor". I guess we should try to distinguish, e.g. "in a Content Editor", "in a Compare Editor", "in the Review Editor". > > > Are we talking about writing the task-data/model -> Gerrit in > > background, allowing changes to be made in review editor without attempting to > > make live changes in the Gerrit model while off-line, or what? > > Yes. A first step in that direction would be submit changes in the background > instead of blocking the user but that to some degree requires caching of the > data, e.g. to handle resubmission in case of errors. Right, this is a really complex issue, as we have multiple modes of interacting with the back end server. As we prepare for in-depth discussion of architecture, I'll see if I can make some sense of these different modes so that we can make some decisions about what pieces to try to support when. Steffen, should we have separate "plan architecture for..." bugs or just arrange that on mailing list..?
(In reply to comment #5) > Steffen, should we have separate "plan architecture for..." bugs or just arrange > that on mailing list..? Yes, makes sense to open another bug and tag it as [discussion]. It would probably be a good idea to notify the mailing list since it's a large architectural change. We usually keep technical discussions on tasks for easier reference and to allow everyone to subscribe based on their interest :).
(In reply to comment #6) > Yes, makes sense to open another bug and tag it as [discussion]. It would bug 400171
See bug 400270 comment 9 and https://git.eclipse.org/r/#/c/11012/ for experimental implementation of offline storage only. The caching doens't actually work properly, but I'll probably have that up and running by March 11 or 12.
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
