Community
Participate
Working Groups
If a long list of subtasks changes it's difficult to determine which subtasks where added and removed in the task list tooltip. Also, task ids are usually not very meaningful. The same applies to CC list changes where the incoming text is suppressed for the same reasons. It would be nice if the tooltip displayed a descriptive message instead, e.g. "Subtasks removed", "CC list changed".
Sam, let me know if you are interested in looking into this.
Sure. I'm thinking something along the lines of the following: Subtasks removed: <indent>1234: Support Custom Fields in... Removed from CC: <indent>person@eclipse.org <indent>joel.user@company.com Added to CC: <indent>someone@eclipse.org or is that too verbose?
That sounds good. We would need to limit the listing to two items or so and add a message that there were more changes.
Another thing that would be nice is to know when there is more than one new comment. Often I can tell from the text of the first new comment that I don't care about it, but I don't know if there are more new comments that I might care about.
Nevermind, it already does that. I guess it could say "0 more" in that case but I don't know if it should.
Created attachment 192984 [details] CC in tooltip This adds CC information to the tooltip. I ended up using a more compact representation thatn I had suggested. While I was at it, I made the existing incoming tooltip make more efficient use of space by * computing the text "(n more)" that can appear after the first new comment earlier so it can be included in the call to trim() * allowing the new (or old) value of an attribute to use any space not used by the old (or new) value It turns out that there is no way to do this for subtasks because we don't know what attribute the connector uses to represent that. Also, the current computation of the string to display for changed attributes, "removed values -> added values", doesn't work for subtasks because it is represented as a single string rather than a list of values, so you see "old value -> new value" instead.
Created attachment 192985 [details] mylyn/context/zip
Created attachment 192991 [details] Interpret Bugzilla dependson as a list Steffen, here's a suggestion on how we could at least make this be consistent with other fields. This would mean that in a long list of subtasks, you would only see the ones that changed, which would be a big improvement. We'd probably want to do this for blocks as well. Other connectors could easily support this too.
Thanks Sam. I would like to move the parsing of the depends on / blocked by fields into TaskAttributeMapper but it looks good otherwise. I'll take another look at this in the next couple of day.
Yeah, I was trying to make the smallest possible change so as not to break anything, but it would be nice if the field were always interpreted as multi-valued.
Sorry, I ran out of time. Let's look at this early in the 3.7 cycle to get this into head.
Sounds good.
I have pushed a review with your change and a suggestion how to handle the dependson attribute in Bugzilla here: http://review.mylyn.org/#change,289 . If I try this I get "Depends on: (removed) -> (added)" which is nice and compact but it's not obvious that values were removed and added rather than the entire attribute value changing. I'll put this on the backlog for now but feel free to push improvements to the review and I'd be happy to reconsider this for 3.7. We would need a few tests to go along with this change as well.
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
