We had no other choice to solve customer woes than to start a closer cooperation with Poznan University of Technology, and a group of excellent students, as a part of their thesis, analysed, designed and coded a separate preferences module, which addresses (almost) all issues in "old" preferences that we have been aware off.
Check out their webcast - it is definitely worth it (for some reason the video does not get displayed on Planet Eclipse, you have to refer to the original blog entry or directly to Youtube).
The code itself requires further work, like adding proper licensing headers, project naming issues, etc. I expect the code will be ready for reviews and donations before the end of month.
Those excellent students that did that thing are:
Marek Kuzora
Anna Ferster
Filip Wisniewski (responsible for the editor)
Congratulations!
Note: Poznan University of Technology has more excellent students which would like to get experience in commercial environment (and write their thesis, too). So if you have any non-business-critical project (or research project) to realize, please drop me a line (krzysztof.daniel somewhere at pl.ibm.com), and I will contact you with appropriate person.
4 comments:
Looks really interesting. Please provide an URL or project name for EclipseLabs.
A good starting point on how to begin an Eclipse project is http://wiki.eclipse.org/Development_Resources
If you need collaboration from other projects it might be best to contact the project leads and ask if the teams will pick up your changes. Since most projects work toward Indigo right now I doubt that you will get quick answers.
Easiest way is to write a project proposal and wait for feedback.
- Achim
I do understand the need for a new preferences model. Yet, I don't see it being solved by yet another API.
For example, the SDK hasn't even managed to find a proper scoping for their preferences. Today, most of the preferences are still in the "instance" scope.
I'm not even talking about migrating to a new API and the effects of backwards compatibility, etc. This may lead to just another "layer of cake" in Eclipse.
IMHO the static grouping isn't helpful. I like thinking of groups as "tags". I may tag preferences differently than others do. For example, I want to export all customized UI settings in one group. This, as a preference produced/developer I have to be able to add my preferences to a third group as well as to my own groups. Somebody else might want to define yet another group "assembled" from already existing preferences.
Hmmm, thinking of it, UI dialog settings aren't even preferences. They are stored differently. Thus, the new API won't help, i.e. it won't allow to export those.
How does a "team" scope play in here? Does JDT need to be hacked in order to support a team scope? Will there be a team scope by default? Will a team scope overrule a project scope? Who defines the team scope?
Lot's of questions. It's a nice effort, though. I just think a new API won't help. The majority of work is reworking all the existing code and - at least in the case of preferences - this hasn't happened in the past. That's why we have five ways of working with preferences currently.
@Gunnar,
let me address some of your concerns:
Yet, I don't see it being solved by yet another API.
New API is inevitable. Current preferences lack of human readable names and are initialized on first reference. You have to define separate extension point if you want to group them somehow for export, and even then not all of them may be exported. Declarative preferences give you all those things for free. Creating a preferene is pretty much like a defining an extension. I think there is no big difference between reworking code to get proper imports/exports and migrating to declarative preferences.
the SDK hasn't even managed to find a proper scoping for their preferences
Manipulating scopes programatically is difficult and developers tend to avoid that unless they really have to. In declarative approach you write no code - just select the scope.
I may tag preferences differently than others do.
This is at least a subject for a discussion over the beer. Import/Export in my opinion should resemble the Windows->Preferences dialog - each preference is listed only once. I am sure we can come up with something that will meet your expectations.
The majority of work is reworking all the existing code
This is true. We will be happy to deliver patches to projects that we see as vital to our customers (JDT, WTP). The patches will be rather low-risk ones.
Anyway, we are completing the wiki and preparing the code for donation. I will follow the Achim advice, and by the end of month I will start the discussion on cross-project newsgroup, and in case of positive response I will fill the project proposal.
I would say that you should have talked to Equinox guys before you started working on this. But I guess you did :-)
I think that this may be a candidate for the e4 incubator, so you should make people aware of the work on the e4-dev mailing list.
Moreover it is too late for such an enhancement in Indigo, even if the Equinox team likes the approach.
I agree with Gunnar about tags vs static groups.
Post a Comment