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
See http://editor.netbeans.org/doc/editor-settings-storage-enhancements.html for
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
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
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
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.