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.
jVi monitors preferences to detect changes that jVi will ignore/override, so that it can put up a dialog if the user changes something that will be ignored. But simply opening Tools>Options and an immediate OK generates lots of change events (assuming editor-options are the last selected in options dialog), including the few tab/shift related ones that jVi cares about. This results in jVi putting up a warning dialog, even though there is nothing to warn about. (FYI jVi maintains these options per Document). (It looks like the change events of interest are only generated for options that had been chagned in the past.) (Many events come from FmtOptions$PreviewPreferences (and do not affect jVi operation), and this discussion and the experimental test patch below does not affect those.) As an experiment, the following checks if the value is the same and simply returns without doing the put if it is. Since the EditorPref's implementation also keeps track of javaType, this would not necessarily work if the same key was saved as a different type. The patch fixes the problem that jvi has. If there is interest, I can fixup the patch as discussed below along with any further suggestions and attach it to this issue. In editor.settings.storage's PreferencesImpl's method public @Override void put(String key, String value) { the following simplistic change takes care of the main issue. @@ -137,6 +137,10 @@ putValueJavaType.set(String.class.getName()); } try { + synchronized(lock) { + if(value != null && getSpi(key).equals(value)) + return; + } super.put(key, value); } finally { if (putValueJavaType.get().equals(String.class.getName())) { ===== The following is a better patch. It has the super.put inside the lock ===== to avoid taking the lock twice. ===== Also, adding the check for a null key as well is needed. try { synchronized(lock) { if(key != null && value != null && getSpi(key).equals(value)) return; super.put(key, value); } } finally {
Thanks for the patch.
Created attachment 66550 [details] simple patch as outlined
Created attachment 66551 [details] simple patch as outlined
Attached the patch as described, does the equals to guarantee no NPE. (got a time out during the attach, reposted; that's why there are two of them)
http://hg.netbeans.org/main/rev/68f1d8fc781f
Integrated into 'main-golden', available in build *200808080201* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/68f1d8fc781f User: Vita Stejskal <vstejskal@netbeans.org> Log: #142723 (fixed): applying Ernie's patch for preference change events when nothing changes
jVi uses the following private static class TabSetListener implements PreferenceChangeListener { public void preferenceChange(PreferenceChangeEvent evt) { .... || SimpleValueNames.SPACES_PER_TAB.equals(settingName) || SimpleValueNames.INDENT_SHIFT_WIDTH.equals(settingName) || SimpleValueNames.EXPAND_TABS.equals(settingName) || SimpleValueNames.TAB_SIZE.equals(settingName)) to detect changes made in the editor options panel and put up a dialog if these are changed which warns that jVi will override these changes. The patch with this issue is now part of editor.settings.storage's PreferencesImpl.java. This used to fix the problem but no longer does. I have not determined exactly where the event to fire is getting added (I'm seeing all 4 of these events) but I'm wondering if perhaps FormattingPanelController/ProxyPreferences is relatively new or has been substantially reworked. I have verified that the code in the patch is not invoked when I hit the OK button; and also that it is invoked when jVi sets one of the options by doing "prefs.putInt(...)" for example.
You could be right. A lot of code around formatting settings panels was added/rewritten.
The events in question (see below for the precise source) have a "newValue" of null. I'm thinking that for now I can just ignore the events with null newValue. What do you think? Additional question. What is the following (probably about those per project settings)? Does jVi care about this? FormattingPanelController.OVERRIDE_GLOBAL_FORMATTING_OPTIONS BTW, should I file an issue about the new per project settings interfering with per file settings that jVi wants to maintain? Product Version: NetBeans IDE 6.5 RC1 (Build 200810171318) Java: 1.6.0_07; Java HotSpot(TM) Client VM 10.0-b23 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Userdir: C:\Documents and Settings\erra\.netbeans\6.5rc1 === === Precise source of events === The source of the events can be traced to public final class FormattingPanelController extends OptionsPanelController { ..... public void applyChanges() { .... // and make sure that they do NOT override basic settings from All Languages for(String mimeType : mimeTypes) { Preferences prefs = MimeLookup.getLookup(mimeType).lookup(Preferences.class); prefs.remove(SimpleValueNames.EXPAND_TABS); prefs.remove(SimpleValueNames.INDENT_SHIFT_WIDTH); prefs.remove(SimpleValueNames.SPACES_PER_TAB); prefs.remove(SimpleValueNames.TAB_SIZE); prefs.remove(SimpleValueNames.TEXT_LIMIT_WIDTH); } arrived at as shown in the following stack trace "AWT-EventQueue-1" java.util.prefs.AbstractPreferences.enqueuePreferenceChangeEvent(AbstractPreferences.java:1527) java.util.prefs.AbstractPreferences.remove(AbstractPreferences.java:298) org.netbeans.modules.options.indentation.ProxyPreferences.flush(ProxyPreferences.java:473) org.netbeans.modules.options.indentation.FormattingPanelController$MimeLookupPreferencesFactory.applyChanges(FormattingPanelController.java:280) org.netbeans.modules.options.indentation.FormattingPanelController.applyChanges(FormattingPanelController.java:119) org.netbeans.modules.options.TabbedController.applyChanges(TabbedController.java:112) org.netbeans.modules.options.CategoryModel$Category.applyChanges(CategoryModel.java:387) org.netbeans.modules.options.CategoryModel$Category.access$1000(CategoryModel.java:311) org.netbeans.modules.options.CategoryModel.save(CategoryModel.java:213) org.netbeans.modules.options.OptionsPanel.save(OptionsPanel.java:202) org.netbeans.modules.options.OptionsDisplayerImpl$OptionsPanelListener.actionPerformed(OptionsDisplayerImpl.java:257) org.netbeans.core.windows.services.NbPresenter$ButtonListener.actionPerformed(NbPresenter.java:1137) ....
BTW, in the loop for(String mimeType : mimeTypes) { there were around 24 mimeTypes in the situation I observed.
I fixed http://hg.netbeans.org/main/rev/ae45de1d253d, could you please try it again? Thanks > I'm thinking that for now I can just ignore the events with null newValue. What do you think? This should be fixed with the above changeset. > FormattingPanelController.OVERRIDE_GLOBAL_FORMATTING_OPTIONS You can ignore this one. > BTW, should I file an issue about the new per project settings interfering with per file settings > that jVi wants to maintain? Umm, I'm not sure. In general, Netbeans does not support per-file formatting settings and there no plans to do so. I think the approach jVi uses is a reasonable compromise. I think jVi should listen on per-project formatting settings the same way as it listens on MimeLookup and display the same warning.
Integrated into 'main-golden', will be available in build *200811061401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ae45de1d253d User: Vita Stejskal <vstejskal@netbeans.org> Log: #142723 - don't fire unneccessary events
I guess we can close this one? Or is there anything left unapplied?
This was fixed by Vita some time ago. No new information so closing for now as fixed.