Community
Participate
Working Groups
Is it possible to mark attachments marked with iplog+ or iplog- with a different color in the table? It is very handy to see obsolete ones in gray. It would be a good thing to down-color iplog attachments as those patches have been applied and need little attention.
I can a patch for this but I think we need a UI representation for flags. Reason: flags are 4state fields and in combination with obsolete we need 8 colors. BTW what is with other flags that can be defined for attachments. Thoughts?
Is the IP log flag something Eclipse specific? If so we should discuss this on a call before adding specific support for that.
(In reply to comment #2) > Is the IP log flag something Eclipse specific? If so we should discuss this on a > call before adding specific support for that. Yes by default there are no flags defined!
Andrew, would it help to display flags in a tooltip? I'm not sure if there is a good way to make them visible in the table without overloading it, particularly if there are many flags.
(In reply to comment #4) > Andrew, would it help to display flags in a tooltip? I'm not sure if there is a > good way to make them visible in the table without overloading it, particularly > if there are many flags. A tooltip is better than nothing, but my request is about being able to tell iplog flag from one glance at the table. I see that a patch has an icon associated with it. What about a small overlay on the image?
(In reply to comment #5) > (In reply to comment #4) > > Andrew, would it help to display flags in a tooltip? I'm not sure if there is a > > good way to make them visible in the table without overloading it, particularly > > if there are many flags. > A tooltip is better than nothing, but my request is about being able to tell > iplog flag from one glance at the table. > I see that a patch has an icon associated with it. What about a small overlay > on the image? The iplog is on possible flag for Eclipse Bugzilla but other do not have this or have more flags that should overlay the image. How should we solve this?
We could consider an Eclipse.org specific extension for Bugzilla but it might not be trivial to support decorations for the attachments table. If it's reasonably generic we could also include it directly in the connector since the project benefits from having Eclipse.org committers using Mylyn.
The request does not fall into the core scope of the project and due to time constraints we are unable to resolve it at the moment. The bug has been marked helpwanted though to indicate that we would be happy to support a community contribution to resolve it. Frank, please feel free to take a crack at it regardless :).
(In reply to comment #7) > We could consider an Eclipse.org specific extension for Bugzilla but it might > not be trivial to support decorations for the attachments table. If it's > reasonably generic we could also include it directly in the connector since the > project benefits from having Eclipse.org committers using Mylyn. What do you think about the following? 1) We can allow to have custom columns in the attachment table showing an TaskAttribute. Then we can have an Bugzilla specific implementation that supports the flags. 2) We implement an repository specific store for setting which custom columns are used 3) Define an UI for add/remove custom columns Thoughts?
(In reply to comment #9) > 1) We can allow to have custom columns in the attachment table showing an > TaskAttribute. > Then we can have an Bugzilla specific implementation that supports the > flags. > 2) We implement an repository specific store for setting which custom columns > are used > 3) Define an UI for add/remove custom columns That sounds like an interesting idea. How would connectors contribute that extra column API wise?
I think we can start with new Method in AbstractRepositoryConnector that add an new metaData field to the TaskAttribute. possible structure of the new method AbstractRepositoryConnector.additionalColumn(TaskAttribute attachmentAttribute) { foreach attribute in attachmentAttribute do { if (metaData match task.meta.type and / or task.meta.label) { add task.meta.tableColumn = column number in table (maybe with information for table header, format of value and compare operation) } With this it should be possible to add bugzilla fields. Maybe without support for multiplicable flags. Thoughts?
Created attachment 174536 [details] mylyn/context/zip
Now that we have migrated to the automatic IP log I miss this functionality all the time. What if we added another column, e.g. Details that populated with text provided by the connector? The approach suggested in comment#16 may also work. Frank, can suggest an API for a TableColumnContributor?
I start with a POC now! Hope that I can have a first version soon.
http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=218ff6409520a1e0f1101e7b2e0511fac4b4214e is the first part I include an refactoring so you can easy create new columns and a way to overwrite the default columns Next step is to overwrite AttachmentTableLabelProvider.getForeground and AttachmentTableLabelProvider.getToolTipText
Created attachment 202627 [details] mylyn/context/zip
Thanks for taking a first pass at this. It looks the changes are still in progress and accidentally (?) ended up in master. I would very much prefer if we staged awesome but extensive changes of this nature that have a risk of introducing regressions and ran tests and did a quick code review before merging them into master. I have noticed that for clean workspaces columns are no longer selected by default in the column selection popup and one test is failing: https://hudson.eclipse.org/hudson/job/mylyn-tasks-nightly/91/. Would it be okay if we reverted the changes in master for now and moved this to a branch?
(In reply to comment #17) > I have noticed that for clean workspaces columns are no longer selected by > default in the column selection popup On second thought, it looks like this is unrelated to the change and has always been the case.
(In reply to comment #17) > Thanks for taking a first pass at this. It looks the changes are still in > progress and accidentally (?) ended up in master. I would very much prefer if > we staged awesome but extensive changes of this nature that have a risk of > introducing regressions and ran tests and did a quick code review before > merging them into master. Yes we should do this. Steffen should we use the new gerrit instance? Mybe I need some help wit setup the workspace. When finished I will update the http://wiki.eclipse.org/Mylyn/Contributor_Reference#Self-hosting_for_Eclipse_3.7 documentation!
Steffen, can you review patch set 4? Now we have an way to a) define AttachmentColumns (subclasses of AttachmentColumnDefinition) b) define AttachmentTableConfiguration that allow to define which Columns are used and the Background, Foreground and Font of an row. To show how this all fit together I implement a DefaultAttachmentTableConfiguration and an BugzillaAttachmentTableConfiguration. But I did not change the Background or Foreground Color because I did not want to change the perestation of incomming Changes or the way obsolate attachments. The Bugzilla Implementation now has an Flag Column.
Created attachment 202836 [details] mylyn/context/zip
The review has been posted here: http://review.mylyn.org/#change,15. Thanks a lot! I'll take a first pass next week.
I have commented on the review. Let me know if you have any questions.
Create a new Patchset. I need to know what should be the new name for class AttachmentColumnDefinition
Steffen, can we do this for 3.7 ? I wait for an input so that i can commit this.
I would prefer if we deferred this. I have put onto the backlog for now. With git the iplog flag is no longer needed in Bugzilla since contributions are now tracked through the author field of the commit.
