We are currently working on an E4 application which must include a Preferences page. We have seen that the EPreferences project has been developed to provide an API for managing the preferences but it seems that no existing project aims at managing the graphical part.
We would like to integrate the Eclipse community and contribute to the Eclipse e4 project by developing a generic Preferences page, similar to the Eclipse 3.x one. If it isn't possible, we will have to develop our own graphical page, which could be moved if a standard one is developed in the future. Our main idea is to base on the EPreferences project and to extend the EMF model to provide a Preferences object which could be use by any application.
As we aren't very familiar with the notion of community, we aren't sure to be on the right way. We invite everyone to bring comments on this. We hope to begin a discussion that will enable us to clarify the functionality that would be beneficial to the Eclipse e4 project.
Please send a mail with the stuff you'd like to work on to the e4-dev
mailing list so that we can discuss there how this work should be
My current believe is that we could hopefully refactor the old
preference page system in a way that we can directly use it in e4
Am 14.10.11 11:11, schrieb etudes-developpements:
> We are currently working on an E4 application which must include a
> Preferences page. We have seen that the EPreferences project has been
> developed to provide an API for managing the preferences but it seems
> that no existing project aims at managing the graphical part.
> We would like to integrate the Eclipse community and contribute to the
> Eclipse e4 project by developing a generic Preferences page, similar to
> the Eclipse 3.x one. If it isn't possible, we will have to develop our
> own graphical page, which could be moved if a standard one is developed
> in the future. Our main idea is to base on the EPreferences project and
> to extend the EMF model to provide a Preferences object which could be
> use by any application.
> As we aren't very familiar with the notion of community, we aren't sure
> to be on the right way. We invite everyone to bring comments on this. We
> hope to begin a discussion that will enable us to clarify the
> functionality that would be beneficial to the Eclipse e4 project.
[This is my personal view and other team members might disagree]
Well everything is important but the most important thing is that the
compat layer is enterprise ready and this where currently all resources
from IBM get dedicated to.
So I don't expect that you get preference editing support for free in
the Eclipse 4.2 Application Platform unless someone from the community
steps up and contributes it.
My 4.2 focus is on 3 things:
* Tooling: Improve the Model-Editor (e.g. integrate search,
* Alternate Rendering: I've a quite good working JavaFX-Renderer
including a declarative DSL
=> JavaFX is the thing most of my current
OSS-Time is spent
* Improve the e4 bridge
* Support for e4 Handlers in 3.x
* Broker-Services e.g. openViews,
On my wish list:
* Tooling for my @Translation injection and pushing it in to the
Eclipse Application Platform
* Native Editor-Support in the Eclipse 4.2 Application Model
* Refactor existing Platform-code parts to run without the Compat layer
on the Eclipse 4.2 Application Platform
* Dialog including Preference Dialogs
* Views like ConsoleView, ...
So while I agree the points on my wish list are important like e.g.
preference editing it's quite unlikely that I'll have the time to
implement (nor I guess the rest of the team will have) them but if I
read the initial post correct this guy/girl is going to implement such a
system and contribute it back
Am 15.10.11 12:56, schrieb St Clair Clarke:
> Hello Tom,
> Why is Preference not seem to be very important to be included in the
> first two releases of e4? Will preference support be included in e4
> release next June/July?
It's relatively easy to populate and popup a preference dialog. I've attached the code I use in Kizby. This uses the more simple JFace preference dialog as the filterable dialog is defined in org.eclipse.ui.
We do need to figure out how to simplify the transition from E3.x to E4.x. We're tracking the issue in bug 350251.
As we haven't received any response concerning this issue by the mailing list (except the one of Brian, thanks for it), we have started to work on it on our side.
We are going to start the specification phase and we would like to submit the result of it to the e4 community but we don't have any idea about the process to follow. So we have some questions:
- Is there any existing format for the specifications?
- Where can we find any information on the validation process?
- Is there any documentation on the different steps for contributing to an e4 feature?
It would also be very interesting for us to have some information about the committers team.
Most of the preferences work is actually split across Equinox and JFace. Platform UI only contributes the filterable dialog and (unfortunately) the ScopedPreferenceStore which provides a bridge between Equinox-style (e.g., InstanceScope, DefaultScope) preferences and JFace-style preferences. The scopes can access any particular plugins' settings.
I'd recommend that, for now, you make a copy of ScopedPreferenceStore. We're looking into how to expose these E3.x and E4.x utility classes in more friendly ways. But it won't be until M4.
St Clair Clarke wrote on Sat, 22 October 2011 13:27
But I am trying to learn how to display Preference pages in eclipse 4.x.
NB: I popup the dialog you posted in e4 - question is how do I now get it to display preference pages. Doing e3.x way will NOT work as e4 is different.
I'm not sure why you think the E3.x way won't work -- Eclipse 4.x doesn't throw everything out from Eclipse 3.x. E4.x started to try to simplify the E3.x APIs that were seen as being inflexible or complicated. And no-one proposed redoing how preferences are presented to the user (yet). You can still use JFace and SWT with an E4.x app; the preferences UI are almost entirely defined in JFace.
"etudes-developpements" is proposing to start defining a modelled preferences approach for Eclipse 4.x. What do you think such a model should look like? What do you find hard about the JFace/E3.x approach to presenting preferences?
I use Google's WindowBuilder Pro (WBP) for development of Preference Pages. WBP has a custom FieldLayoutPreferencePage that allows the use of both Standard SWT/JFace widgets as well as FieldEditors. It also allows a GridLayout which is more flexible. Please consider giving us this option during your preference development.
I was asked about the licensing of the code that I posted above -- for those countries that do not have a concept of 'public domain', please consider the code as being licensed under the UnLicense (unlicense.org).
Eclipse Platform committer. Ask me about Eclipse support, training, and consulting.