Community
Participate
Working Groups
Attachments are accompanied with attachment information but users are currently forced to scroll up to the Attachments section and locate the associated attachment. It would be more convenient if the attachment could be acted upon from the comment.
I really like this idea.
Need to defer: http://wiki.eclipse.org/index.php/Mylyn/3.0_Plan#Deferred_Items
Created attachment 163181 [details] patch 1) Attachments are now included in the Outline view. If you select the attachment in the Outline in the Attachment table is the one entry get selected. 2) in the TaskPerferencePage in Advanced you can now switch the Hyperlink for attachment to show the attachment in the editor attachment table and not use the browser. Is this what we want to have? Thoughts?
Created attachment 163182 [details] mylyn/context/zip
The patch looks good. I have two suggestions for improvement before it is applied: * TaskAttachmentHyperlink should call TaskEditor.selectReveal() and fall back to the browser if the method returns null. The passed object should potentially be a URI pointing to the attachment. TaskEditorAttachmentPart will need to implement setFormInput() to handle revealing of (attachment) URIs. See TaskEditorCommentPart for an example. The outline should use the same mechanism to reveal the selected attachment. * The label provider code that detects image filenames should be generalized somewhere and use a set to lookup well known extensions or better use the content type of the corresponding attachment attribute. I am not sure if a new preference to control opening of attachments is needed. This would only be be used Bugzilla at the moment, right? I'll bring this up on Thursday's call for discussion.
As discussed on the call we'll try opening all attachment links in the task editor initially. If that turns out to be problematic, e.g. since clicking a link will cause the editor to scroll and hence cause loss of context, we can revisit this in the future. It was also suggested to add a menu to attachment hyperlinks that gives users a choice to either open the link in the editor or browser. This could work through the multi hyperlink presenter from platform or through a popup menu. Frank, it would be great if you could consider removing the preference for now and the suggestions from comment 5 and attach a new patch.
I'll put this on for 3.5. We are almost done but out of time to get this in for 3.4.
Created attachment 173583 [details] updated patch here a patch with an popup menu for selecting which method we should use for show the attachment.
Created attachment 173584 [details] mylyn/context/zip
Instead of creating a custom popup menu this should reuse the multi-hyperlink presenter from platform. You can simply return multiple hyperlink objects for the same portion of text in BugzillaConnectorUi.findHyperlinks(). Otherwise the patch looks good to me just exclude changes to AbstractTaskEditorPage and EditorUtil before committing.
Created attachment 176402 [details] patch for non mac Please can someone try this on an none Mac CPU (see bug# 322293)
Created attachment 176403 [details] mylyn/context/zip
Created attachment 176404 [details] patch with workaround Here a patch with an workaround for the Mac.
Created attachment 176405 [details] mylyn/context/zip
The "patch for non mac" works well for me. The only thing that needs to be changed are the labels for the links to make it more clear which link opens the attachment in the browser and which opens it in the editor. Let's hold off with committing until we have clarification how to deal with bug# 322293.
If someone here could build a Mylyn plugin with the proposed patch that's crashing on Cocoa I can take a look. The stack trace in bug 322293 is out of date and I can't match it up with the current code.
Created attachment 187141 [details] patch V5 (In reply to comment #16) > If someone here could build a Mylyn plugin with the proposed patch that's > crashing on Cocoa I can take a look. The stack trace in bug 322293 is out of > date and I can't match it up with the current code. This is the updated Patch. Steffen can I commit this patch for the next build and when will this be accessible?
Created attachment 187142 [details] mylyn/context/zip
Looks good to me. Please feel free to commit and I'll try to produce a new build.
Created attachment 187327 [details] patch V6 here the commited patch. bug#322293 is fixed in Eclipse version "3.7.0.v201101192000" so we can enable it.
Created attachment 187328 [details] mylyn/context/zip
Created attachment 187342 [details] reverted changes Some of the changes broke the build and introduced some side effects. Frank, can you take a look at the patch that I committed?
(In reply to comment #22) > Created attachment 187342 [details] > reverted changes > > Some of the changes broke the build and introduced some side effects. Frank, can > you take a look at the patch that I committed? Steffen, why did you remove in AbstractTaskEditorPage.selectReveal(Object object) if (object instanceof TaskEditorOutlineNode) { } this is needed because TaskAttachmentTableEditorHyperlink.open() use page.selectReveal(TaskAttribute.PREFIX_ATTACHMENT + attachmentId). I found no other place where selectReveal() is used wit an String Object as parameter. Without this code there is no difference between the two Hyperlinks.
Created attachment 187361 [details] patch V7 committed patch. Here the fix so that Show Attachment works.
(In reply to comment #23) > why did you remove in AbstractTaskEditorPage.selectReveal(Object object) [...] > I found no other place where selectReveal() is used wit an String Object as > parameter. > > Without this code there is no difference between the two Hyperlinks. The changes didn't look right to me and not necessary. Looks like your last patch fixed it. I have tweaked the label of the hyperlink slightly to say "Show ... in Task Editor". Looks like we are done here. Thanks!
