Community
Participate
Working Groups
Currently I can define in PreferenceInitilizer also in e4 RCP. <extension point="org.eclipse.core.runtime.preferences"> <initializer class="preferences.CustomPreferenceInitializer"> </initializer> </extension> package preferences; import org.eclipse.core.runtime.preferences.AbstractPreferenceInitializer; import org.eclipse.core.runtime.preferences.DefaultScope; import org.eclipse.core.runtime.preferences.IEclipsePreferences; import org.eclipse.core.runtime.preferences.InstanceScope; import org.osgi.service.prefs.BackingStoreException; public class CustomPreferenceInitializer extends AbstractPreferenceInitializer { @Override public void initializeDefaultPreferences() { System.out.println("Preference initializer"); IEclipsePreferences node = InstanceScope.INSTANCE.getNode("test"); // auto-refresh default node.putBoolean("auto", true); try { node.flush(); } catch (BackingStoreException e) { e.printStackTrace(); } } } But AFAIK we do not have a e4 way of calling this. Is this a lack of knowledge on my side, or do we need additional functionality here?
Oliver / Alexander, are you aware of an e4 way of initializing preferences?
(In reply to Lars Vogel from comment #1) > Oliver / Alexander, are you aware of an e4 way of initializing preferences? I think we don't have a special e4 way of preference initialization. Or maybe I don't know that. Honestly I cannot claim the current way of initialization to be "counter-e4" as it does not enforce us to use E3 classes. Actually it looks like just a hook to run preference-related code. I suppose you can do similar things from any OSGi component. @Lars How the "e4" initialization should look from your perspective?
Hi ! Sure I use this way, but with the defaultScope, like in this training file here : https://github.com/opcoach/training/blob/master/e4/com.opcoach.training.e4.rental.ui/src/com/opcoach/training/e4/rental/ui/pref/RentalPrefInit.java My https://github.com/opcoach/e4Preferences GitHub project which is provided on my repository here : https://opcoach.com/repository/ is my solution to deal with preferences as it is unfortunately not manageable in the application model. This plugin can mix, without any constraint, both E4 pure preferences and E3 preferences.
(In reply to Olivier Prouvost from comment #3) > > This plugin can mix, without any constraint, both E4 pure preferences and E3 > preferences. What is "E3 preferences"? Do you mean the preferences managed by E3 bundles like "org.eclipse.ui.workbench" and friends?
Yes, I mean preferences pages and values defined using the extension point : org.eclipse.ui.preferencePages and org.eclipse.core.runtime.preferences
(In reply to Olivier Prouvost from comment #5) > Yes, I mean preferences pages and values defined using the extension point : > org.eclipse.ui.preferencePages and org.eclipse.core.runtime.preferences This is interesting, because IMO "org.eclipse.core.runtime.preferences" looks more or less neutral to E4 world (yes, formally it is a part of E3 API). The JFace preference support also doesn't care a lot about Workbench and seems neutral to E4 world. But this is a bit different subject. At the moment it looks like none of us can point to the "very special pure e4 way of initializing preferences".
Hi Alexander, You are right, core.runtime.preferences has no E4 UI concerns. And for the preferenceDialog it is managed by JFace and its PreferenceManager -> so no E4 ui concerns This is why the project I provide uses the PreferenceManager initialized by the runtime (for E3 starter application), or by me for E4 starter application. It allows to mix preferences pages defined either with my extension point (com.opcoach.e4.preferencePage) or with the eclipse extension (org.eclipse.ui.preferencePage). You can reuse page's category defined in E3 in your E4 pages. The goal of this plugin is to complete the model fragment concept and to create plugins that are totally written using E4 concepts but that can also be mixed also with plugins still written in E3 mode.
Maybe we should move ScopedPreferenceStore to a new e4 bundle?
(In reply to Lars Vogel from comment #8) > Maybe we should move ScopedPreferenceStore to a new e4 bundle? Or at least drop the unnecessary localization for the log message that introduces the UI dependency. At least IIRC it is at least one issue with that class.
(In reply to Lars Vogel from comment #8) > Maybe we should move ScopedPreferenceStore to a new e4 bundle? Generally sounds good. But this may lead to a "package split" that may have a lot of consequences. I still remember my attempt to extract "Problem view" to e4 that was abandoned due to "package split".
(In reply to Dirk Fauth from comment #9) > (In reply to Lars Vogel from comment #8) > > Maybe we should move ScopedPreferenceStore to a new e4 bundle? > > Or at least drop the unnecessary localization for the log message that > introduces the UI dependency. At least IIRC it is at least one issue with > that class. Can you push a Gerrit for this suggestion? You are still the master of localization. :-)
(In reply to Lars Vogel from comment #11) > (In reply to Dirk Fauth from comment #9) > > (In reply to Lars Vogel from comment #8) > > > Maybe we should move ScopedPreferenceStore to a new e4 bundle? > > > > Or at least drop the unnecessary localization for the log message that > > introduces the UI dependency. At least IIRC it is at least one issue with > > that class. > > Can you push a Gerrit for this suggestion? You are still the master of > localization. :-) Not sure how it should look like. Do we really need a localized log message here? I would simply log an English standard message
(In reply to Dirk Fauth from comment #12) > (In reply to Lars Vogel from comment #11) > > (In reply to Dirk Fauth from comment #9) > > > (In reply to Lars Vogel from comment #8) > > > > Maybe we should move ScopedPreferenceStore to a new e4 bundle? > > > > > > Or at least drop the unnecessary localization for the log message that > > > introduces the UI dependency. At least IIRC it is at least one issue with > > > that class. > > > > Can you push a Gerrit for this suggestion? You are still the master of > > localization. :-) > > Not sure how it should look like. Do we really need a localized log message > here? I would simply log an English standard message +1
Hi lars, Yes the core.runtime.preferences is totally operational in a pure E4 application. But in your code you should use the default scope instead of InstanceScope : @Override public void initializeDefaultPreferences() { System.out.println("Preference initializer"); IEclipsePreferences node = **DefaultScope**.INSTANCE.getNode("test"); // auto-refresh default node.putBoolean("auto", true); try { node.flush(); } catch (BackingStoreException e) { e.printStackTrace(); } }
Sorry I received an old notification ... my comment #14 answers to the first text of this... Another point of view about a pure migration in E4... We should have PreferencePages in the application model, and the renderer for JFace would parse the model to initialize the preferenceManager.... Hierarchy for pages would be clearly visible instead of the 'flat' extensions view...
(In reply to Lars Vogel from comment #13) > (In reply to Dirk Fauth from comment #12) > > (In reply to Lars Vogel from comment #11) > > > (In reply to Dirk Fauth from comment #9) > > > > (In reply to Lars Vogel from comment #8) > > > > > Maybe we should move ScopedPreferenceStore to a new e4 bundle? > > > > > > > > Or at least drop the unnecessary localization for the log message that > > > > introduces the UI dependency. At least IIRC it is at least one issue with > > > > that class. > > > > > > Can you push a Gerrit for this suggestion? You are still the master of > > > localization. :-) > > > > Not sure how it should look like. Do we really need a localized log message > > here? I would simply log an English standard message > > +1 Sorry for the late reply. I had a quick look and remembered the issue with ScopedPreferenceStore. Actually there are two: 1. It is inside org.eclipse.ui.workbench, which makes it impossible to use it in a plain e4 application 2. It uses org.eclipse.ui.internal.WorkbenchMessages for an Assertion log statement (IMHO unnecessary for such an error, as it should point a developer to the issue, not an end user) If we want to move it, we need to drop the localized message. That is not a big deal I guess. But as Alexander already mentioned, we get a split package issue if we keep the package as is for backwards compatibility. The only solution I could think of would be to: 1. drop the localized Assert log to get rid of the org.eclipse.ui dependency in ScopedPreferenceStore 2. Move ScopedPreferenceStore to an e4 bundle (new / existing ?) 3. Keep a ScopedPreferenceStore in org.eclipse.ui.workbench that extends the extracted one in the new package. That one only forwards the method calls to the moved ScopedPreferenceStore. This way we: a) could have a ScopedPreferenceStore independent of org.eclipse.ui b) avoid the split package by introducing a new package c) do not break existing implementations, as we keep a wrapper in the original package, although we should mark that one as deprecated, so we can drop that wrapper in the future, as it would only exist for backwards compatibility With such a change we can then even think about getting the preferences solution from Olivier [1] and my DS based preferences solution [2] merged into the platform. Not sure if this would be of any interest though. [1] https://github.com/opcoach/e4Preferences [2] https://github.com/fipro78/e4-preferences
