Community
Participate
Working Groups
For the Generic SQL Connector with reference implementation in Derby we store all task artifacts in SQL tables. This means that an attachment such as a screen shot is stored in an sql BLOB field. We can store and retrieve allright but double clicking and opening in Default editor mostly fail. We store file name and mime type, so enough info is available to select a default editor on double click, but the open in Browser handler get the double click action, even when no URL is specified. I propose we change these handlers so that when no URL is specified but the mime type is openable by browser , the blob data is downloaded from the DB and stored in a TEMP location and opened with a file:// URL instead. This will give rapid double click access to screenshots. When the attachment is java, or zip we handle it differently.
Created attachment 113796 [details] mylyn/context/zip
Maarten, does the current implementation of "Open With > Default Editor" always work for the generic web connector? If that is the case it could be a good argument to make that the default action. It certainly would make sense to not show "Open With Browser" if no url is set. Would you be interested in providing a patch for that?
Created attachment 114038 [details] Isn't this what we really want? Instead of just Default Editor, why not reuse the Open with... menu options also found in the package explorer.
Yes, that would be even better.
Created attachment 114090 [details] patch that extends browser handler with file:// option When the attchment is not accessible as a URL, but does contain a file name, a local temporary copyis created and opened with a file URL. It resolves te display screendumps in a non-url (BLOB) based attachment store.
Created attachment 114091 [details] mylyn/context/zip
Bugs 249463 and some others would give reason to believe that you cannot specify an (default) editor for an external file, this precludes downloading to /temp/ and opening an editor (vs a browser) from there. Bug 230865 being fixed, that should no longer be a problem. But to use proper content scanning, I understand the attachment repository should be an IFileStore. Also I think that attachments to bugs are usually read only, so how does that match with the Open in Default Editor behavior now?
The patch looks good Maarten. I am still not sure how to reorganize the menu (bug 220314). I will bring this up on the next conference call and then apply your patch.
An important point was raised on today's conference call: If an attachment is implicitly downloaded to a local file it become confusing if a user edits the attachment but local changes are not be saved back to the repository. Therefore it was decided to not support this in the tasks framework. To satisfy your use case I would suggest that the generic sql connector contributes a new menu item, e.g. "Save and Open with Browser" to the context menu of the attachment table using the implementation in your patch. I'll mark this bug as wontfix since support for offline attachments is out of the scope of the project.
(In reply to comment #9) > To satisfy your use case I would suggest that the generic sql connector > contributes a new menu item, e.g. "Save and Open with Browser" to the context > menu of the attachment table using the implementation in your patch. Can we then make the TaskAttachment object queryable with an IActionFilter implementation for the object: I propose stuff like hasUrl,hasHttpUrl, hasMimeType, hasFilename to disable and enamble various actions so we would not get the void response with the existing Open in Browser action?
You can register a property tester. Here is a an example from the plugin.xml of tasks.ui: <propertyTester class="org.eclipse.mylyn.internal.tasks.ui.util.TaskAttachmentPropertyTester" id="org.eclipse.mylyn.tasks.ui.propertyTester.task.attachment" namespace="org.eclipse.mylyn.task.attachment" properties="isContext" type="org.eclipse.mylyn.tasks.core.ITaskAttachment"> </propertyTester>
I still think that double click - open browser without URL is a bug so must be patch to tasks.ui and those actions must be enabled based on URL present. Agree?
It is planed to remap the double click action to open in default browser (bug 220314). We could consider additional extensibility in the attachment part of the task editor to allow connectors to change the default behavior.
