Community
Participate
Working Groups
This should be very straightforward to implement: we get the time from the history view entry, and we make the task editor scroll to the corresponding comment. If scrolling it is too hard it can just auto-expand for now.
Tentatively scheduling for M2.
Need to defer: http://wiki.eclipse.org/index.php/Mylyn/3.0_Plan#Deferred_Items
I think that this provides a big bang for the buck, so tentatively raising priority for 3.1.
In terms of API I am thinking that it could make sense to provide an extensible class similar to IMarker which allows setting of custom attributes. An instance of this would be passed to the editor page such as a comment id, attachment id or attribute id and the page would make the corresponding UI element visible.
I wonder if we coudl have simle API for select/reveal which takes an IPath of string values? Eg, * [ Comments, 4 ] * [Attributes, Severity]
I don't think it's a good idea to include the path since that is specific to the layout of the editor whereas most clients of the API will operate on the model (the selection listener in AbstractTaskEditorPage.updateOutlinePage() provides that functionality already). I can see the following model elements that would be useful to support for select/reveal: * attribute (by id) * comment (by number, id) * attachment (by name?)
Created attachment 153117 [details] POC This is a POC that use the patch of bug# 250257 to implement support of attachments in the outline view. If you select an attachment the row in the table is highlighted.
Created attachment 153118 [details] mylyn/context/zip
Changes for bug 301756 have been completed which provides basic infrastructure for revealing elements in the task editor. To resolve this bug a listener would need to be registered in OpenCorrespondingTaskAction that invokes selectReveal() on the editor when the task is opened. The listener would need to pass the attribute id of the comment that is to be revealed. Not sure what the priority of implementing this is. Moving to the backlog.
>This should be very straightforward to implement: we get the time from the history view entry, and we make the task editor scroll to the >corresponding comment. If scrolling it is too hard it can just auto-expand for now. I did not know how the mapping between the commit time and a comment time can work. I think that we get never an match. What we can implement is that we try to open the comment that is next after the commit time. Thoughts?
Created attachment 161181 [details] mylyn/context/zip
Yes, showing the comment posted after a commit was made sounds like the best approximation.
Created attachment 163114 [details] patch Here a patch. Keep in mind that the time in the cvs viev show no seconds so you can not see if the selected comment is the right one.
Created attachment 163115 [details] mylyn/context/zip
Patch looks good to me. I am wondering though if using Date instead of long as the type for the time stamp would make the API more descriptive? One thing that needs to be changed is that we need to keep the TasksUiUtil.openTask(String repositoryUrl, String taskId, String fullUrl) method and delegate to the new method with the time stamp parameter since the method is API.
(In reply to comment #15) > Patch looks good to me. I am wondering though if using Date instead of long as > the type for the time stamp would make the API more descriptive? Do you mean that I change long to java.sql.Timestamp? > > One thing that needs to be changed is that we need to keep the > TasksUiUtil.openTask(String repositoryUrl, String taskId, String fullUrl) method > and delegate to the new method with the time stamp parameter since the method is > API. Changed to public static boolean openTask(String repositoryUrl, String taskId, String fullUrl, long timestamp)
I was thinking of java.util.Date instead of using long but long has the advantage of being immutable so it could be the better choice.
Created attachment 168854 [details] commited patch API change from comment#15 is included
Created attachment 168855 [details] mylyn/context/zip
patch is now in HEAD
Thanks! Frank, please make sure to add your name to the copyright header of all files you modified and an @author tag to all files where you made significant changes.
