Community
Participate
Working Groups
Created attachment 285311 [details] Initial code (unfinished) Provide a utility to persist and restore perspectives in E4 applications including the parts' states. Provide a utility to migrate persisted e3 perspectives. This is not a finished implementation but could potentially be contributed in the future if there is interest for this. The attachment serves as publishing the existing code as EPL v2.
Sounds good, is it planned to use this also in the IDE for configuring perspectives?
At the moment it is targeted to provide the feature set via an API so that you integrate it into a custom Eclipse 4 application. If the IDE wants to pick this up, that is fine, but we have currently no plans to integrate it into the IDE
Created attachment 285314 [details] Initial code with slight improvements (unfinished) So far it is only planned as a utility. Slightly improved version of the code.
(In reply to Lucas Koehler from comment #3) > Created attachment 285314 [details] > Initial code with slight improvements (unfinished) > > So far it is only planned as a utility. > Slightly improved version of the code. Lucas, can you please put this in a Gerrit?
@Wim: We will eventually move this to Gerrit when we get closer to a contributable state. So please consider this BR as a pre-publish of the current state on the road to a contribution.
Would it be possible to "reset" the perspective with fresh data from the e4xmi, or is this working from the persisted model?
We finished the integration of this migration helper in a second project now. The migration for sure does not yet cover all cases, but it would probably be of great help for anybody who needs to migrate persisted state. We would like to contribute this as a stand-alone features, i.e. not part of the platform or IDE distribution. It will essentially provide API to do the migration which allows to integrate the migration into any product. Any opinions about this?
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/185779
(In reply to Jonas Helming from comment #8) > We would like to contribute this as a stand-alone features, i.e. not part of > the platform or IDE distribution. It will essentially provide API to do the > migration which allows to integrate the migration into any product. I'm not really enthusiast about Platform providing some API it has no use for at the moment. It basically means we increase maintenance cost without increasing the value of the SDK, nor actually increase the API value for the mass (as so far this is not a popular request). IMO, to merge it into Platform, we need at least 1 for the following criteria to be fulfilled: * The code is profitable and used for the SDK (can be in JDT or PDE as well) and its users * This is a popular issue/request from multiple RCP providers; popular enough to consider it's an important criterion of success for RCP development and hence we can include it in Platform. Note that I'm not judging about how useful it is; I sincerely don't know and trust it is at least very useful to you. But if you can find some other interested customers for this feature; it will facilitate its inclusion in Platform.
(In reply to Mickael Istria from comment #10) Should it go to PDE?
We have already used this for several projects that needed this and I expect more to come. This is the reason we initially published the code under EPL so that it can be reused by multiple adopters. Please be aware that especially in the RCP area, many tools are not even yet migrated to 4.x. Please also be aware that we contribute this as a proxy for several adopting parties.
(In reply to Jonas Helming from comment #12) > We have already used this for several projects that needed this and I expect > more to come. This is the reason we initially published the code under EPL > so that it can be reused by multiple adopters. Please be aware that > especially in the RCP area, many tools are not even yet migrated to 4.x. > Please also be aware that we contribute this as a proxy for several adopting > parties. Yes, this is a major issue for all E4 RCP clients. Including us.
(In reply to Wim Jongman from comment #11) > Should it go to PDE? Who's the final user of this feature and when is it used (by use, understand "run" here)? Would it be possible to include an example together with this contribution; or to reuse those APIs in an existing example?
There are two use cases: - Save and restore: This can be used in any RCP application that wants to allow users to persist and load perspectives. Please note that perspectives are not necessarily stored locally, but might be stored in a data base. The API allows this flexible use case. - Migrate 3.x workbench states to Eclipse 4: This can be used when a project that offered persist perspectives on 3.x wants to migrate the user data from 3.x to Eclipse 4. So this is relevant only at the time when migrating to 4.x
(In reply to Jonas Helming from comment #15) > Please note that perspectives > are not necessarily stored locally, but might be stored in a data base. The > API allows this flexible use case. Is this (non local file backend) something you're using? If there is no need for flexibility, let's avoid it in Platform; that will be less APIs to care about for 20 more years. > - Migrate 3.x workbench states to Eclipse 4: This can be used when a project > that offered persist perspectives on 3.x wants to migrate the user data from > 3.x to Eclipse 4. So this is relevant only at the time when migrating to 4.x OK, so it should be part of the "compatibility" part, shouldn't it? Can both features be decoupled; so one would be in Platform UI, and the other would be in e4 compatibilty parts?
(In reply to Mickael Istria from comment #16) > (In reply to Jonas Helming from comment #15) > > Please note that perspectives > > are not necessarily stored locally, but might be stored in a data base. The > > API allows this flexible use case. > > Is this (non local file backend) something you're using? If there is no need > for flexibility, let's avoid it in Platform; that will be less APIs to care > about for 20 more years. I think my description was not clear. The contribution does not provide any API to store in files, data bases or anything. It just operates on Strings. Any adopter can implement the persistence as they want. So the API is very minimal. > > > - Migrate 3.x workbench states to Eclipse 4: This can be used when a project > > that offered persist perspectives on 3.x wants to migrate the user data from > > 3.x to Eclipse 4. So this is relevant only at the time when migrating to 4.x > > OK, so it should be part of the "compatibility" part, shouldn't it? > > Can both features be decoupled; so one would be in Platform UI, and the > other would be in e4 compatibilty parts? Yes, sounds like a good idea!
I double checked the code and its internal dependencies. Both parts namely the Save and Restore for e4 applications as well as the Migration from 3.x to e4 are using the same internal model to describe the workbench state. Of course we could remove the functionality that requires it (storing e4 Perspective back as 3.x compatible state) or duplicate the model. But in any other case the compatibility package (org.eclipse.ui.workbench/Eclipse UI/org/eclipse/ui/internal/e4/compatibility ?) would have a dependency to the new bundle. Because of this quite tight coupling I suggest to keep this a one bundle. Maybe I totally misunderstood your suggestion where to add the new bundle to and how to split the code?
I split the code, I hope the naming makes sense for you. A feedback to the split and naming would be very welcome.
