Community
Participate
Working Groups
When doing a CVS compare with head, I notice that the two halves of the compare show differences, but that there are no "links" between the two halves -- indicating how the differences line up. Also, when moving one scroll bar, only one half moves; the editors do not stay in line with each other. I200404270800. Linux GTK+ 2.4.0.
*** Bug 60190 has been marked as a duplicate of this bug. ***
The default preference settings for the preference page are no longer respected. Since I didn't change anything in that area for months, I suspect a problem somewhere else. The workaround is to enable the "Synchronize Scrolling..." preference manually. Moving to platform UI for comment.
It seems that the method AbstractUIPlugin.initializeDefaultPluginPreferences doesn't get called for the CompareUIPlugin. Did I miss any change in that area?
Nick, you've recently made changes to the preference support... could this be a regression caused by those changes?
The changes to how prefs are initialized in the workbench should not affect compare's preference initialization. There have been changes to core preference initialization which may have affected this. DJ, can you investigate?
CompareUIPlugin.startup initializes the preference store which in turn tries to initialize the default values. The new mechanism gets the plug-in descriptor from the registry and then calls #getPlugin. The plug-in object returned is not CompareUIPlugin but is a generic plug-in object since we are still in the startup/initialization of this plug-in. (thus when the #initializeDefaultPluginPreferences method is called, its not called on the compare plug-in) I will investigate further and talk to the runtime folk.
Oops, I made a typo in my previous comment...it should have said that the initialization is done in the CompareUIPlugin constructor. (not #startup) Here is a small test case which exhibits the same behaviour: public class MyPlugin extends Plugin { private static final String PLUGIN_ID = "com.example"; public MyPlugin(IPluginDescriptor descriptor) { super(descriptor); Platform.getPlugin(PLUGIN_ID); // returns generic plug-in object } } The plug-in object isn't finished being initialized so its not yet available via the plug-in registry. The old runtime preferences wrapper the new mechanism and at that time they know which plug-in object they are calling from. I will investigate passing this down into the implementation of the default nodes. Either way, the story going forward is that the following code will still result in the same problem. But if a plug-in is accessing the preference store via the new APIs (IEclipsePreferences#node) then they must use the extension point to specify their preference initializer and not rely on the 2.1 behaviour. public class MyPlugin extends Plugin { private static final String PLUGIN_ID = "com.example"; public MyPlugin(IPluginDescriptor descriptor) { super(descriptor); IPreferencesService service = Platform.getPreferencesService(); // returns generic plug-in object service.getRootNode().node(DefaultScope.SCOPE).node(PLUGIN_ID); } }
Fix released to HEAD.
