Bug 59458 - Define editor settings classes retrievable through MimeLookup
Define editor settings classes retrievable through MimeLookup
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: Settings
5.x
All All
: P2 (vote)
: 6.x
Assigned To: issues@editor
issues@editor
plan61
: API, API_REVIEW_FAST, PLAN, UI
Depends on: 59784
Blocks: 90403
  Show dependency treegraph
 
Reported: 2005-06-01 09:16 UTC by Miloslav Metelka
Modified: 2008-01-10 10:04 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
:


Attachments
Integrating the new storage for macros (15.26 KB, text/plain)
2007-12-11 11:52 UTC, Vitezslav Stejskal
Details
java.util.prefs.Preferences implementation in MimeLookup (183.22 KB, text/plain)
2008-01-10 10:01 UTC, Vitezslav Stejskal
Details
Commit log (merge to trunk) (7.32 KB, text/plain)
2008-01-10 10:02 UTC, Vitezslav Stejskal
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Miloslav Metelka 2005-06-01 09:16:33 UTC
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.
Comment 1 Martin Roskanin 2005-06-09 14:04:47 UTC
The prototype of the editor settings API is ready in the 'editor_api' branch.
The new module exists under cvs/editor/settings 
Comment 2 Vitezslav Stejskal 2006-07-02 23:11:11 UTC
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.
Comment 3 Vitezslav Stejskal 2006-12-01 02:41:50 UTC
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.
Comment 4 Vitezslav Stejskal 2007-06-14 09:58:13 UTC
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.
Comment 5 Vitezslav Stejskal 2007-12-11 11:52:38 UTC
Created attachment 54138 [details]
Integrating the new storage for macros
Comment 6 Vitezslav Stejskal 2007-12-11 11:56:44 UTC
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.
Comment 7 Vitezslav Stejskal 2007-12-11 11:58:41 UTC
The remaining part of this issue is the storage and API for 'simple value settings'. Please stay tuned for a design
proposal.
Comment 8 Vitezslav Stejskal 2007-12-11 16:32:08 UTC
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);
Comment 9 Vitezslav Stejskal 2007-12-11 16:49:01 UTC
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
Comment 10 Vitezslav Stejskal 2008-01-10 10:00:39 UTC
This has been done, I'm going to attach diffs and commit-log and close this task.
Comment 11 Vitezslav Stejskal 2008-01-10 10:01:40 UTC
Created attachment 54905 [details]
java.util.prefs.Preferences implementation in MimeLookup
Comment 12 Vitezslav Stejskal 2008-01-10 10:02:38 UTC
Created attachment 54907 [details]
Commit log (merge to trunk)
Comment 13 Vitezslav Stejskal 2008-01-10 10:04:13 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo