Community
Participate
Working Groups
'Add Attachment' button on a task editor pops up a dialog that has room for comment text. The comment text area should support all of the same features as the task editor new comment section: * content-assist * taskEditorExtension (WikiText) * hyperlink detection * spell check
Created attachment 115582 [details] initial draft of integration Integration working with the attached patch. Outstanding issues: * Keybindings aren't working. For example, F1 doesn't show the markup cheat sheet and CTRL-Space doesn't invoke content assist
Created attachment 115583 [details] initial draft of integration Integration working with the attached patch. Outstanding issues: * Keybindings aren't working. For example, F1 doesn't show the markup cheat sheet and CTRL-Space doesn't invoke content assist
I apologize for the double-posting... Mylyn told me 'unable to send attachment' so I pressed submit again.
Created attachment 115584 [details] mylyn/context/zip
The patch duplicates a lot of the functionality implemented in RichTextAttributeEditor. The intention of the original design of the attribute editor and AttributeEditorFactory was to make it reusable outside of the task editor. Have you considered using that instead?
(In reply to comment #5) > The patch duplicates a lot of the functionality implemented in > RichTextAttributeEditor. The intention of the original design of the attribute > editor and AttributeEditorFactory was to make it reusable outside of the task > editor. Have you considered using that instead? > It was not clear to me how to use an attribute editor without an TaskAttribute or TaskData, which the RichTextAttributeEditor requires. Is it possible to use AttributeEditorFactory without these? I opted for the 'simpler is better' approach in this case, knowing that there was a fair amount of code duplication. I figured that once the design solidified we could refactor out the common functionality.
The TaskAttachementModel.getAttribute() returns a task attribute that has child attributes for the properties that can be edited in the wizard. Currently TaskAttachmentPage relies on connectors using a default schema for attachments that is specified in TaskAttachmentMapper. It would be nice to replace this with a more extensible implementation that reuses the attribute editor factory.
(In reply to comment #7) > The TaskAttachementModel.getAttribute() returns a task attribute that has child > attributes for the properties that can be edited in the wizard. Great! I'm having troubles finding a way to get access to a TaskDataModel, which is required to use an AbstractAttributeEditor of any kind. Any suggestions?
Good point. The coupling is a bit unfortunate but we could consider extending TaskAttachmentModel to hold a reference to the TaskDataModel. I'll have to look at that in more detail to understand the implications better.
(In reply to comment #9) > Good point. The coupling is a bit unfortunate but we could consider extending > TaskAttachmentModel to hold a reference to the TaskDataModel. I'll have to look > at that in more detail to understand the implications better. I've taken a quick look through and have come up with some questions regarding implementation using the AbstractAttributeEditor: # is the TaskAttachmentModel.attribute member the attribute that corresponds to the attachment comment? # when the attribute is modified, would this cause the underlying editor to become modified due to events propagated through the TaskDataModel? ## should the TaskAttachmentPage listen for such change events to apply the value? # attribute editors make use of a FormToolkit. Should the dialog be refactored to use such a toolkit for other fields/controls? I'm just trying to make sense of it all here. Also are you aware of a way to use context activation in a dialog to activate specific keybindings? It's not clear to me how to get an IContextService for a dialog.
> # is the TaskAttachmentModel.attribute member the attribute that corresponds to > the attachment comment? No, it's a container attribute that stores the description in a child attribute (see TaskAttachmentMapper.applyTo()). > # when the attribute is modified, would this cause the underlying editor to > become modified due to events propagated through the TaskDataModel? The attributeChanged() calls would have to be filtered by a wrapper class to avoid that. > ## should the TaskAttachmentPage listen for such change events to apply the > value? The attribute editor commits the value to the attribute when it's modified. > # attribute editors make use of a FormToolkit. Should the dialog be refactored > to use such a toolkit for other fields/controls? We could probably get away with making the toolkit optional. I believe it's discouraged to use the form look in dialogs but I haven't checked the Eclipse UI guide lines. > Also are you aware of a way to use context activation in a dialog to activate > specific keybindings? It's not clear to me how to get an IContextService for a > dialog. Is this available from the workbench, e.g. PlatformUI.getWorkbench().getService(IContextService.class)?
(In reply to comment #11) I hate to say it but so far it looks like a lot of complexity for a small amount of code reuse. It's too bad because at first glance the attribute editors appear to be the way to go. I'm not going to cut another patch on this one unless the groundwork has been laid out regarding the TaskDataModel, etc. If you decide that you'd like to go ahead with the design of the existing patch I'll look into the keybinding service context issue. > > > Also are you aware of a way to use context activation in a dialog to activate > > specific keybindings? It's not clear to me how to get an IContextService for a dialog. > > Is this available from the workbench, e.g. > PlatformUI.getWorkbench().getService(IContextService.class)? I've tried that but it doesn't work. Needs more investigation.
(In reply to comment #12) > > Is this available from the workbench, e.g. > > PlatformUI.getWorkbench().getService(IContextService.class)? > > I've tried that but it doesn't work. Needs more investigation. Looks like the relevant info is here: http://dev.eclipse.org/newslists/news.eclipse.platform/msg66416.html
Please consider for 3.2
David, I'll take this for now to investigate if we can go with an approach similar to yours but share more code between RichTextAttributeEditor, TaskEditorNotesPart and the attachment page.
Great! Good luck!
Created attachment 137274 [details] patch
Created attachment 137275 [details] mylyn/context/zip
I have extracted the common text editing bits into a new class named RichTextEditor which is now shared by the task editor and attachment dialog. David, in order to enable key-bindings for content assist, you have activate the corresponding command handlers. CommonTextSupport provides a convenience method which installs a focus listener that does that. Let me know if spell checking and WikiText markup works for you. If we also wanted to provide a preview or unformatted text view we could consider adding a context menu which would also be useful for Cut/Copy/Paste.
*** Bug 265213 has been marked as a duplicate of this bug. ***
Nice work! It looks awesome! (In reply to comment #19) > I have extracted the common text editing bits into a new class named > RichTextEditor which is now shared by the task editor and attachment dialog. RichTextEditor looks great! Nice how it simplifies RichTextAttributeEditor. > David, in order to enable key-bindings for content assist, you have activate the > corresponding command handlers. CommonTextSupport provides a convenience method > which installs a focus listener that does that. Good to know. This seems to be a partial solution since there are other commands that are not being activated, such as the quick outline and show cheat sheet commands. Normally these are activated by the platform because they're associated with a context: bc. <extension point="org.eclipse.ui.bindings"> <!-- win32: M1=CTRL, M2=SHIFT, M3=ALT, M4=- carbon: M1=COMMAND, M2=SHIFT, M3=ALT, M4=CTRL --> <key sequence="F1" contextId="org.eclipse.mylyn.wikitext.ui.editor.markupSourceContext" commandId="org.eclipse.mylyn.wikitext.ui.editor.showCheatSheetCommand" schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"> </key> <key sequence="M1+O" contextId="org.eclipse.mylyn.wikitext.ui.editor.markupSourceContext" commandId="org.eclipse.mylyn.wikitext.ui.quickOutlineCommand" schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"> </key> </extension> I wonder if there's a way to have the solution activate the commands correctly based on the context? Something like this: bc. IContextService contextService = (IContextService) site.getService(IContextService.class); contextService.activateContext(CONTEXT); > Let me know if spell checking and WikiText markup works for you. yes, it works, as does content assist > If we also wanted to provide a preview or unformatted text view we could consider adding a > context menu which would also be useful for Cut/Copy/Paste. Sounds like a good idea to me -- though it may make it hard for the user to get out of preview mode.
I'll have to investigate the context activation. It looks like the bindings for the markupSourceContext are not activated even though the context is active. If I change the key-binding to work in "Dialogs and Windows" I can make the outline appear.
