Bugzilla – Full Text Bug Listing
| Summary: | [wikitext] Task repository should have a properties field where configuration settings can be made | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Jingwen 'Owen' Ou <jingweno> | ||||||||||||||||||
| Component: | Mylyn | Assignee: | Jingwen 'Owen' Ou <jingweno> | ||||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||||
| Severity: | enhancement | ||||||||||||||||||||
| Priority: | P1 | CC: | greensopinion, steffen.pingel | ||||||||||||||||||
| Version: | unspecified | ||||||||||||||||||||
| Target Milestone: | 1.0.0 | ||||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||||
| OS: | Windows XP | ||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||
|
Description
Jingwen 'Owen' Ou
Owen, can you extract the relevant parts from David's patch on bug 234210? Based on that we can iterate over the design. Created attachment 105347 [details]
extracted relevant parts from Davd's patch
please compare it with the original file, key line starts from 486
Sorry, I should have been more clear. My intention was to only extract the parts that add the settings to the page instead of creating a copy of the whole class. How about this: Instead of modifying the setting page the sandbox could contribute an submenu to the popup menu of the task repositories view that allows the selection of the desired task editor extension. This page has some examples how to contribute dynamic menus: http://wiki.eclipse.org/Menu_Contributions . What do you think? (In reply to comment #3) > How about this: Instead of modifying the setting page the sandbox could > contribute an submenu to the popup menu of the task repositories view that > allows the selection of the desired task editor extension. This page has some > examples how to contribute dynamic menus: > http://wiki.eclipse.org/Menu_Contributions . What do you think? In the short-term this might be fine, but for a long-term solution I would prefer to see the setting in the properties dialog. This is where the user would expect to see it. (In reply to comment #4) > In the short-term this might be fine, but for a long-term solution I would > prefer to see the setting in the properties dialog. This is where the user > would expect to see it. Yes, it definitely makes sense to aggregate the settings in the dialog for Mylyn 3.1 either by making the settings page extensible or adding to the abstract class. For now the popup menu is the best option I can think of to contribute to. (In reply to comment #5) > Yes, it definitely makes sense to aggregate the settings in the dialog for > Mylyn 3.1 either by making the settings page extensible or adding to the > abstract class. For now the popup menu is the best option I can think of to > contribute to. Agreed. I guess that's the cost of having a sandbox. We'll just have to remember to integrate them later. Owen, can you try take the code from the patch in AbstractRepositorySettingsPage that configures the task editor extension and make that a menu contribution in the Sandbox? The releveant parts of the code is in this chunk:
if (needsEditorExtensionSelector()) {
...
}
Instead of using a combo box you could try to contribute a submenu in the popup menu of task repositories view (see comment 3).
Created attachment 105848 [details]
contribute a popup menu to TaskRepositoryView
Daivd, right now only Textile style works? When I switched to other makrup language (confluence), it doesn't seem working
(In reply to comment #8) > Daivd, right now only Textile style works? When I switched to other makrup > language (confluence), it doesn't seem working Owen, it works for me! (Nice work) Note that a changed editor extension setting currently only affects newly opened editors. A couple of other things that I noticed about your patch: * the submenu items should indicate which one is the default setting for the repository. You can get this with @TaskEditorExtensions.getDefaultTaskEditorExtensionId(taskRepository)@ * the submenu should provide an option that sets it to 'None', so that the extension can be turned off Created attachment 105957 [details]
all-in-one patch adding "none" and default setting for the repository
David, would it be possible that you added a null editor style using TaskEditorExtensions.addTaskEditorExtension() then when TaskeEditorExtensions.getTaskEditorExtensions() and the null editor extension always return first, so that we don't need to treat no style as a special style (no style is also a kind of style)
detail please refer to EditorStyleContributionItems.getContributionItems()
> Created an attachment (id=105957)
> all-in-one patch adding "none" and default setting for the repository
>
> David, would it be possible that you added a null editor style using
> TaskEditorExtensions.addTaskEditorExtension() then when
> TaskeEditorExtensions.getTaskEditorExtensions() and the null editor extension
> always return first, so that we don't need to treat no style as a special style
> (no style is also a kind of style)
(In reply to comment #10) > David, would it be possible that you added a null editor style using > TaskEditorExtensions.addTaskEditorExtension() then when > TaskeEditorExtensions.getTaskEditorExtensions() and the null editor extension > always return first, so that we don't need to treat no style as a special style > (no style is also a kind of style) No, that's a bad idea (sorry). The place where this concern should be handled is where the menu is constructed. > No, that's a bad idea (sorry). The place where this concern should be handled
> is where the menu is constructed.
Ok, but you may need to treat "None" in saving the editor style setting as well, so that the users can get back the configuration next time.
(In reply to comment #13) > Ok, but you may need to treat "None" in saving the editor style setting as > well, so that the users can get back the configuration next time. > I agree. The original patch was able to store a 'none' or null setting and have it stick so that next time a user opens an issue editor the editor does not use any extension. The "None" menu should basically do the same thing. Great patch Owen! I have applied it with one minor changes: I chose singular for the class name to be consistent with the name of the super class. I have renamed the menu item to "Task Editor Extension" since it is a generic extension that is not limited to WikiText. I agree that the "None" state is a UI concern and should be handled in the menu contribution rather than the extension. I don't think it is a big deal that the setting does not apply to open editors. Refreshing the editors would require saving and additional user interaction. I think we should keep it the way it is for now and improve it in case there are requests from the community. Owen, it would be great if could attach contexts with the patches just check attach context in the task editor. You can "cleanup" the context from the context page in the task editor in case it contains irrelevant items. Please close this bug if it resolved. Persisting the "None" selection seemed to work fine for me. Created attachment 105980 [details]
mylyn/context/zip
Created attachment 105981 [details]
visibility test
I just noticed that the setting is enabled for all repositories. Owen, could you add an expression that makes sure that the menu is only visible for bugzilla repositories? I have attached a patch with an example. To make that work you'll have to implement a property tester for TaskRepository object. You can use TaskPropertyTester as an example. Created attachment 106068 [details]
a patch adding a PropertyTester
Steffen, ur welcomed to make more request. U too, David. :)
Created attachment 106069 [details]
mylyn/context/zip
(In reply to comment #15) > Great patch Owen! I have applied it with one minor changes: I chose singular for > the class name to be consistent with the name of the super class. I have renamed > the menu item to "Task Editor Extension" since it is a generic extension that is > not limited to WikiText. no problem, this is what I am here for :). > I agree that the "None" state is a UI concern and should be handled in the menu > contribution rather than the extension. I don't think it is a big deal that the > setting does not apply to open editors. Refreshing the editors would require > saving and additional user interaction. I think we should keep it the way it is > for now and improve it in case there are requests from the community. after a careful consideration, maybe you guys are right: the "None" is an UI concern and should go to where its created > Owen, it would be great if could attach contexts with the patches just check > attach context in the task editor. You can "cleanup" the context from the > context page in the task editor in case it contains irrelevant items. done with the latest patch and will be in the future...personally I seldom download context unless to pinpoint classes I don't know. But it seems its a good practise to let people know what you have uploaded relating to their workspaces. > Please close this bug if it resolved. Persisting the "None" selection seemed to > work fine for me. yup, it does work. Any more requests for this bug? If not, I might close it. Created attachment 106070 [details]
mylyn/context/zip
a more accurate context, ignore the pre one
Marking resolved. (In reply to comment #23) > Marking resolved. Steffen, did you apply the last patch which enables the setting only for bugzilla? Or plans change? Thanks for catching that! I have applied the outstanding patch. Great work! |