Community
Participate
Working Groups
Some people refer to attachments by attachment id. The id is not present in Attachments table and one got to scan the comments to figure it out. It would be also neat to keep comment# in the table, there is enough space for that. I think Mylyn can do better than Bugzilla for that one too.
I'm -1 for putting this into the table since it would clutter the UI with information that is needed infrequently. My sense is that attachments are usually referenced to by bug id which is prominently visible in the task editor. We have also optimized the editor to work on small screen so that it doesn't require more than 600px width by default. I think that it would be useful to include this information in the tooltip though and maybe provide a Copy Details context menu. Would that satisfy your requirements Andrew?
Created attachment 152198 [details] illustration Let me attach a screenshot to illustrate the problem. Which attachment is mentioned in action 13? I had several of those in the past few days, although I admit references like that are infrequent. Tooltip would be some help but some bugs do have a dozen of attachments or so. Maybe there could be some control or preference for expanded table?
What about a small icon against a (folded) comment having an attachment? That would help to spot those.
I agree that having an affordance to access attachments from the corresponding comment would be very helpful: bug 199283: [api] make attachments actionable from associated comment in task editor https://bugs.eclipse.org/bugs/show_bug.cgi?id=199283 If columns were configurable making an ID column available would make sense to me. I have added a comment to bug 250257. Please consider vothin for that.
(In reply to comment #4) > If columns were configurable making an ID column available would make sense to > me. I have added a comment to bug 250257. Please consider vothin for that. Thanks for considering options. I wanted to vote but it is not possible to vote from Mylyn if no votes present yet :)
Frank, would you be interested in looking into implementing the UI for this? Based on a discussion with Mik the best thing that we could come up with is to show a popup menu when the user right clicks on the table header. The menu should show a check item for each table column to show/hide it and a Reset item to restore the defaults. This should be implemented generically in TableViewerSupport so that it can be reused for other tables as well.
(In reply to comment #6) > Frank, would you be interested in looking into implementing the UI for this? > Based on a discussion with Mik the best thing that we could come up with is to > show a popup menu when the user right clicks on the table header. The menu > should show a check item for each table column to show/hide it and a Reset item > to restore the defaults. This should be implemented generically in > TableViewerSupport so that it can be reused for other tables as well. OK, I start soon.
Created attachment 176276 [details] commited patch patch is in HEAD
Created attachment 176277 [details] mylyn/context/zip
Please verify with the next weekly build.
The patch is now reverted, so we can close bug# 322405. I look for an other implementation. Sorry
Created attachment 176395 [details] commited patch V2 Here the correction of the first patch.
Created attachment 176396 [details] mylyn/context/zip
(In reply to comment #11) > The patch is now reverted, so we can close bug# 322405. > > I look for an other implementation. > > Sorry The correction is now in HEAD.
