Community
Participate
Working Groups
Once https://bugs.eclipse.org/bugs/show_bug.cgi?id=528419 will be fixed UI Preferences should provide the capability to enable/disable CodeMining providers Window / Preferences should provide: * a "General / Editors / Text Editors / Code Mining" entry menu to open CodeMining preference page * CodeMining preference page must display a table with CodeMining providers (registered by extension point). Each provider line must be checkable to enable/disable provider. Please note this CodeMining preference page will be improved in another issues to: * display each minings managed by the provider (because provider can manage several type of mining) to enable/disable it. is In this case atree will be used (provider on the root and managed minings in the children). * configure default preferences of mining (color, font, etc) * configure custom preferences of minings (ex : choose icons for a kind of mining, etc). In this case a new extension point should be provided to customize the UI of mining configuration. * sort the provider, minings.
I think this one can be perceived as low priority at the moment, and it's fine if not shipped in Photon.
> I think this one can be perceived as low priority at the moment, and it's fine if not shipped in Photon. I think enable/disable CodeMining is very important. I would like just provide this simple UI preferences to enable/disable CodeMining for JDT editor for instance. For the other topics, I understand it's advanced features. I wanted just to share my ideas.
(In reply to Angelo ZERR from comment #2) > I think enable/disable CodeMining is very important. I would like just > provide this simple UI preferences to enable/disable CodeMining for JDT > editor for instance. So far, my experience with generic editor which can receive a lot of extensions is that it takes some time before user actually wants to enable/disable features. Users just want good feature to work and dislike tweaking stuff; so it was not a priority for the generic editor, didn't get implemented and so far, so good, no-one complained. To me, this falls in the nice-to-have list, not a must-have.
If we decide to implement CodeMining with JDT Java Editor. We cannot provide CodeMining by default and don't give the capability to disable it. I think it's very important to disable CodeMining because I'm sure that some people will not like mining and if there is problem with performance, user will disable it. CodeMining is like hyperlink, completion, annotations which needs to customize.
(In reply to Angelo ZERR from comment #4) > If we decide to implement CodeMining with JDT Java Editor. We cannot provide CodeMining by default and don't give the capability to > disable it. In this case, shouldn't the bug be retargeted to JDT? > I think it's very important to disable CodeMining because I'm sure that some > people will not like mining and if there is problem with performance, user > will disable it. If there is a problem with performance, then the problem about performance should be fixed with higher priority than a workaround to disable the cause ;) > CodeMining is like hyperlink, completion, annotations which needs to > customize. As mentioned, I thought the same 1.5 years ago for the Generic Editor, and it seems like this is not what user focus on, at all.
> In this case, shouldn't the bug be retargeted to JDT? I would like to avoid doing that, in other words avoid that each project must implement their preferences to enable/disable mining although we can do that with a commons preferences page like hyperlink, spelling, etc. Just to clarify the things, customize color, font of minings is not very interesting (I agree with you), but customize which minings you wish to display or not is very very important IMHO. Just for your information, I have almost finished to implement this preference page.
(In reply to Angelo ZERR from comment #6) > Just to clarify the things, customize color, font of minings is not very > interesting (I agree with you) Unless we find an already existing font definition to reuse (would be best), ability to customize font/color is actually very important to handle theming properly. > customize which minings you wish to display or not is very very important IMHO. OK. I'm still not convinced but... > Just for your information, I have almost finished to implement this > preference page. ...if it's already done, it's for sure something that makes sense to integrate.
> Unless we find an already existing font definition to reuse (would be best), ability to customize font/color is actually very important to handle theming properly. +1 I will start implementing something to configure mining with preferences store. > OK. I'm still not convinced but... -( I wanted to convince you! > ...if it's already done, it's for sure something that makes sense to integrate. Very cool! I'm waiting for your review and accept https://bugs.eclipse.org/bugs/show_bug.cgi?id=528419 to create a new gerrit patch about that.
Created attachment 272146 [details] Enable CodeMining With Preferences Demo @Mickael, here a demo which enable/disable code mining with UI preferences. I will create a gerrit patch about that, but it will be a big patch -( I must clean my code, but here how it works: * codeMiningProviders can manage one or several minings. In this demo you can see that JUnit code minings manage 3 code minings type (status, run, debug). To specify that, you declare 3 "configuration" elements like this: ------------------------------------------------------------------------------ <extension point="org.eclipse.ui.workbench.texteditor.codeMiningProviders"> <codeMiningProvider class="org.eclipse.jdt.junit.codemining.JUnitCodeMiningProvider" id="org.eclipse.jdt.junit.codemining" label="%JUnitCodeMiningProvider.label"> <configuration id="status" label="Show Status"> </configuration> <configuration id="run" label="Show Run"> </configuration> <configuration id="debug" label="Show Debug"> </configuration> <enabledWhen> <with variable="editorInput"> <adapt type="org.eclipse.core.resources.IFile"> <test property="org.eclipse.core.resources.contentTypeId" value="org.eclipse.jdt.core.javaSource" /> </adapt> </with> </enabledWhen> </codeMiningProvider> </extension> ------------------------------------------------------------------------------ You can see in the UI preferences the "Show Debug", etc in the tree of CodeMining preference page that you can check/uncheck. * ICodeMiningProvider has a new configure method like this: ------------------------------------------------------------------------------ public interface ICodeMiningProvider { void configure(ICodeMiningProviderConfiguration configuration); ------------------------------------------------------------------------------ * ICodeMiningProviderConfiguration looks like this: ------------------------------------------------------------------------------ public interface ICodeMiningProviderConfiguration { boolean isEnabled(String codeMiningId); ------------------------------------------------------------------------------ In another gerrit patch, I will add capability to configure color, font for the mining (with the "configuration" element). * to know if status code mining must be enabled, you must just call configuration.isEnabled like this: ------------------------------------------------------------------------------ public class JUnitCodeMiningProvider extends AbstractCodeMiningProvider { @Override public void configure(ICodeMiningProviderConfiguration configuration) { this.configuration = configuration; } private boolean isStatusCodeMiningsEnabled() { return configuration.isEnabled("status"); } @Override public CompletableFuture<List<? extends ICodeMining>> provideCodeMinings(ITextViewer viewer, IProgressMonitor monitor) { return CompletableFuture.supplyAsync(() -> { if (isStatusCodeMiningsEnabled()) { // Add status code mining .... } ------------------------------------------------------------------------------ The preferences are stored inside "org.eclipse.ui.editors.prefs" file. It stores only preferences when mining is disabled. I store a property per codeming to disable like this : ------------------------------------------------------------------------------ org.eclipse.jdt.junit.codemining.run.enabled=false org.eclipse.jdt.junit.codemining.status.enabled=false ------------------------------------------------------------------------------ As you can notice , I don't store a list of disabled codemings I find it's more readable and in other gerrit patch, I would like to store other preferences like color and font like this: ------------------------------------------------------------------------------ org.eclipse.jdt.junit.codemining.debug.color=125,125,125 ------------------------------------------------------------------------------ Hope you will like the idea.
@Mickael, I'm cleaning my code to create a gerrit patch. Have you some suggestions about demo and my explanation about my idea? Do you like it?
Experience with code minings show that a generic approach doesn't seem to be necessary and individual preferences in well designed pages are to be preferred.
