Community
Participate
Working Groups
Task attributes that specify the TaskAttribute#META_ATTRIBUTE_MEDIA_TYPE metadata should be displayed with the appropriate RichTextEditor markup extension. This setting could override the repository default setting.
Proposal https://git.eclipse.org/r/#/c/19880/
Thanks for picking this up, Leo!
I think we need to make this behaviour clear in the UI somehow. Here is one approach: 20160: 424188: indicate that repository markup setting may be overridden [I8da533d9] https://git.eclipse.org/r/#/c/20160/
Any reason to keep the settings in the UI for connectors that specify the markup type?
In case a connector specifies it for only some attributes. But maybe we shouldn't worry about that case. If we remove the setting from the UI, note that the same part is used for enabling Gravatar images so we need to keep that part of it.
(In reply to comment #5) > In case a connector specifies it for only some attributes. But maybe we > shouldn't worry about that case. +1 > If we remove the setting from the UI, note that > the same part is used for enabling Gravatar images so we need to keep that part > of it. That makes sense.
Actually, after talking with Leo, there is no good way to determine whether a connector specifies the markup type without having task data, so it would be much simpler to just keep the settings there and make it clear what the behaviou is.
(In reply to comment #7) > Actually, after talking with Leo, there is no good way to determine whether a > connector specifies the markup type without having task data, so it would be > much simpler to just keep the settings there and make it clear what the behaviou > is. We would need a new capability in the connector to advertise that the connector provides proper meta-data.
That could be a problem for dynamically contributed connectors. Dynamic connector contributors would need to be able to determine which of their connectors provide this metadata. They can't assume that all do, because e.g. a Bugzilla connector shouldn't specify a markup language.
(In reply to comment #9) > That could be a problem for dynamically contributed connectors. Dynamic > connector contributors would need to be able to determine which of their > connectors provide this metadata. They can't assume that all do, because e.g. a > Bugzilla connector shouldn't specify a markup language. I'm not sure I understand that comment. A connector should have sufficient information to determine whether task data specifies a markup type or not. I don't see how that's different for dynamically contributed connectors.
The problem is that it would require dynamic connector contributors to have something in their API to identify whether a connector specifies markup types, and they have indicated that they don't want to do this. I don't think it's worth iterating on this any more - updating the UI to say that the setting can be overriden seems good enough, and additionally means we support the case where a connector doesn't specify markup type for all attributes.
One major limitation that we have right now is that TaskEditorExtensionReader doesn't pick up dynamic HTML based markup types contributed by MarkupLanguageProviders. Have you looked at adding that? I'm not sure how well HTML renders with WikiText anyways but I wonder if we should support that as a general concept.
We haven't looked at that. I guess we would need to create a MarkupTaskEditorExtension for each MarkupLanguage and add it to TaskEditorExtensions. The tricky part is that MarkupLanguages are provided by ServiceLocator in wikitext.core, so we'd need to do something like having a wrapper for ServiceLocator in wikitext.tasks.ui and way for TaskEditorExtensions to call it through an extension point. Is there a simpler way?
I'm don't think the current mechanism is sufficient or well suited for runtime contributions. It could be time to extend or replace the extension point with a contribution mechanism that is more flexible.
That sounds like it's out of scope for this task. Feel free to open another and suggest a contribution mechanism.
Thanks very much, Leo, for the contribution!
