This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Define classes describing the editor settings that will be provided in the MimeLookup (defined by issue 59009). Rewrite the editor settings retrieval to the new settings classes. Once the new options will be in place the original options (BaseOptions-like classes) can be dropped.
The prototype of the editor settings API is ready in the 'editor_api' branch. The new module exists under cvs/editor/settings
The editor/settings module is in trunk now. The only thing that remains is to add SimpleValueSettings class that would provide support for primitive type settings. It'll have to be API reviewed.
There is actually more work needed than just implementing SimpleValueSettings. The editor/settings/storage does not provide any implementation of o.n.api.editor.settings.CodeTemplateSettings and there is also no way for retrieving macro definitions from MimeLookup. This has to be done before we can deprecate BaseOptions. See http://editor.netbeans.org/doc/editor-settings-storage-enhancements.html for more details.
We won't be able to finish this in time for 6.0M10. We added CodeTemplatesSettings and added new storage for code templates, but we still need to upgrade storage for macros and simple-value-settings (ie. properties). Please see issue #90403 for more details.
Created attachment 54138 [details] Integrating the new storage for macros
The storage for macros now lives in editor/macros module alongside with all the other macros related code like recording and executing macros, Tools-Options -> Editor -> Macros panel, etc. Since no 'other' modules have ever needed to access macros programatically (except for contributing their own macros via an XML layer) there was no need for public settings classes. Hence none was created. Please see the attached commit log for details on the changes made.
The remaining part of this issue is the storage and API for 'simple value settings'. Please stay tuned for a design proposal.
The proposal for an API class that would allow access to 'simple value' editor settings is simple - let's re-use java.util.prefs.Preferences. This was originally mentioned in issue #90403 and I mentioned two problems with this approach. #1 - j.u.p.Preferences does not support additional 'simple' types that the editor infrastructure needs, mainly java.awt.Color and java.awt.Insets #2 - j.u.p.Preferences provides read-write access to settings, which is in contrary to the rest of the API classes in o.n.api.editor.settings package. After re-thinking this again I believe that none of those really apply. Here is why: re #1 - First, any j.a.Color settings should arguably be maintained under coloring profiles and therefore be accessible through o.n.api.editor.settings.FontColorSettings. As for j.a.Insets settings they are only used in the editor infrastructure, which can implement proper conversion by itself. So, in general modules don't use these settings and thus we don't need to design an API support for them. re #2 - The idea was that the API classes for accessing the editor settings should be read-only and retrievable from MimeLookup, where they should be replaced an-block by their provider to avoid semantic inconsistencies. This works fine for complex settings like fonts&colors or keybindings, when clients want to see the whole new/updated coloring profile or keymap. We can relax this rule for simple value settings, because they generally work in a different way. The particular simple value settings are usually unrelated, so it is not important to shield clients from partial changes. Also since the editor settings are normally both modified and used from user invoked actions, the modification and usage rarely happens simultaneously (eg. you either change something in Tools-Options or work in the editor, but you never do this at the same time). Finally, if for some reason we would need to apply tighter control over the changes made through j.u.p.Preferences we should be able to do that in a compatible way. For example by subclassing j.u.p.Preferences and providing lock/unlock methods. Here is an example of how this could work: Preferences prefs = MimeLookup.getLookup("text/x-java").lookup(Preferences.class); boolean camelCase = prefs.getBoolean("use-camel-case", true);
I'd like to ask for the fast track review of the proposal for using java.util.prefs.Preferences for accessing the 'simple value' editor settings. Since there is not going to be any physical API created I'm merely asking for a review of the concept described earlier in this issue. I'm asking for the fast track review, but as usually if this is found controversial I'll use full review. Thank you
This has been done, I'm going to attach diffs and commit-log and close this task.
Created attachment 54905 [details] java.util.prefs.Preferences implementation in MimeLookup
Created attachment 54907 [details] Commit log (merge to trunk)
All editor settings types are now accessible through MimeLookup - for the simple value settings we added an implementation of java.util.prefs.Preferences as described in the original proposal.