Community
Participate
Working Groups
The task editor currently creates a single viewer per comment. We have often discussed the idea of switching to a single viewer to render all comments (potentially speeding up render time). Lets use this bug report to track prototyping this idea.
It can resolve the bug#206568 problem.
Yup! But I'm still hoping that we can let the UI be the driver for this instead of performance. We should be able to get the performance profile right with laziness, since task editors should not open with a large number of comments expanded.
http://www.eclipse.org/articles/Article-Folding-in-Eclipse-Text-Editors/folding.html
Created attachment 83193 [details] Interation 1 Quick experimentation to see how this all works. Code is functional so you can get a feel for what this might be like. Would need further improvements including coloration of comment header etc, investate icon decoration either inline or in an additional ruler column. Hyperlinking all works as it should. I think this has potential and it really does improve render time. I don't have numbers to support yet but it appears to be at least twice as fast when the bug has significant number of comments.
Created attachment 83194 [details] mylyn/context/zip
Created attachment 83195 [details] Iteration 1 Screenshot Sample of what this looks like in the TaskEditor
Wau Rob! This is so cool. Few things need special attention: -- some issue trackers (i.e. JIRA) allow to edit comments after posting. -- some other trackers are using richer formatting (track wiki editor/preview integration) -- need syntax highlighting (i.e. bloden up comment header) -- that action bar on the left, can it be global for the whole form editor instead of sitting inside comments section?
(In reply to comment #7) > Wau Rob! This is so cool. Few things need special attention: Yes, this is pretty cool stuff although you've raised some good points as to why this may not be a suitable direction... > -- some issue trackers (i.e. JIRA) allow to edit comments after posting. This shouldn't be a problem assuming you can lock down regions of a document (i.e. make the comment headers non-editable) > -- some other trackers are using richer formatting (track wiki editor/preview > integration) This is what I see as the major blocker to this approach, although we could consider using this as a way to render old comments and use full viewers for new comments only... not certain. > -- need syntax highlighting (i.e. bloden up comment header) yup > -- that action bar on the left, can it be global for the whole form editor > instead of sitting inside comments section? My guess is the ruler needs to be installed on a per viewer basis but I could be wrong.
(In reply to comment #8) > ...assuming you can lock down regions of a document Do you have any pointers for that by any chance? I needed something like that in some other place but couldn't figure out how to do that > > -- some other trackers are using richer formatting (track wiki editor/preview > > integration) > This is what I see as the major blocker to this approach, although we could > consider using this as a way to render old comments and use full viewers for new > comments only... not certain. I wonder if RTF editor will be sufficient for that, not sure though if it does work with the folding api. I can't apply your patch because of the conflicts with other patches that waiting reviews for too long. BTW, what happens with the idea to show only new + last N comments by default?
I don't think that we will be able to get sufficiently high a fidelity UI with this approach. One of the main problems is that Fitts law (http://en.wikipedia.org/wiki/Fitts'_law ) means that in order to make the collapsing easy to click, we will have to make the comment sections work like widgets. The small ruler widgets will be very hard to click. Making the editor act like widgets will be a slippery slope, because editors are not meant to act like widgets, but like editable text regions. Also, this will get in the way of Browser-based comment rendering, which is coming increasingly higher on the radar for JIRA and Trac. Let's discuss further during tomorrow's call. This is not to say that we don't need to get the performance to be equivalent to what it would be with a single editor, we do. But unless there is compelling evidence that we can make the UI easy enough to use we should be careful how much more time we invest in this approach (i.e. needs to be as as easy as GMail, since that kind of interaction was our goal before GMail came around, and can be nowhere near as hard as the current folding UI in Eclipse).
One more thing to add to list is to support keyboard based navigation, and for example, ability to copy text across multiple comments.
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
