[e4] Support registration of PreferencePages with E4

[laeubi]

Currently it is not possible to add a PreferencePage using E4 to the usual Window > Preferences because org.eclipse.ui.internal.dialogs.WorkbenchPreferenceManager only handles pages from the extension point org.eclipse.ui.preferencePages even though the PreferenceManager itself is already looked up by the E4 Context.

The goal would be to have a new Type preferencePages under the application model:

here one can add new PreferencePage with the properties:

• class
• label
• category

because of the way E4 works, we don't need any specialization like IWorkbenchPreferencePage and can use the plain JFace PreferencePage here.

[fipro78]

I implemented a plain E4 mechanism based on OSGi DS a while ago.

https://github.com/fipro78/e4-preferences

Maybe it helps.

[laeubi]

@fipro78 many thanks for sharing this, the main pitfall is what I highlighted here:

To open a JFace PreferenceDialog that looks similar to the known Eclipse workbench preference dialog, you need to create a handler that looks similar to the following snippet

So currently there is no way (beside open a complete new/different dialog) for a plugin to contribute this in an application independent way (e.g inside the usual Eclipse-IDE), that's what then can be used e.g. by Eclipse IDE or even by your implementation where one can have a custom handler.

[laeubi]

Actually there is a workaround to achieve this with a standard Eclipse Workbench I described it here:

https://github.com/eclipse-platform/eclipse.platform.ui/wiki/Rich-Client-Platform#registering-preference-pages-using-e4

@fipro78 if you would use a ContextFunction you don't need the annotation to inject the manager and it would be similar possible to what I described there as option (2) to add pages that need E4 injection.

[fipro78]

@laeubi
Thanks for the hint. I think I tried to use a IContextFunction in the past, and failed because of a cycling dependency. I came across this again now, but this time I was able to solve it. :)

fipro78/e4-preferences@f2a3e8a

So now my mechanism uses a ContextFunction and there is no need anymore for the annotation.

[merks]

Would it not be better/easier to define a new extension point that's effectively a copy of the current one, but has no workbench dependencies? I imagine much of the implementation could just be "moved down" to that new implementation.

The following is quite complex example where the label is translated, the class specifies the factory to be used to create the page instance, and it specifies a reference to the keywords that can be used to easily locate a preference on the page:

I'm trying to imagine how all this this fits into the UI model. It seems there is nothing really quite analogous in the model currently which makes me wonder how it should fit and whether it is a good fit...

[laeubi]

Would it not be better/easier to define a new extension point that's effectively a copy of the current one, but has no workbench dependencies?

The E4 Model is "the extension point", especially because otherwise the dependency injection won't work and one can't target a specific application.

Translation should already be possible: https://wiki.eclipse.org/Eclipse4/RCP/Modeled_UI/Localization

Keywords is something I would like to omit for the moment, but one can specify a property fro that later on when it becomes relevant but keywords are acutally also an E3 concept that I'm not sure there is any match in E4