Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 371087

Summary:

[EAP] No way to store UI-State like in 3.x with IMemento

Product:

[Eclipse Project] Platform

Reporter:

Thomas Schindl <tom.schindl>

Component:

Assignee:

Thomas Schindl <tom.schindl>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

bsd, daniel_megert, emoffatt, Lars.Vogel, ob1.eclipse, pwebster, remy.suen

Version:

4.2

Target Milestone:

4.2 M6

Hardware:

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

Bug Depends on:

348069

Bug Blocks:

Attachments:

Description	Flags
Annotation	none
Modification to PartRenderingEngine	none
revised patch	none

Description Thomas Schindl

2012-02-09 09:31:33 EST

The current EAP does not allow to persist the state in a way RCP 3.x allowed save the state by implementing IViewPart#saveState(). 

In EAP we only have @PreDestroy as a lifecycle which is not good because at this moment e.g. SWT-Widgets are already disposed and saving their state in ApplicationElement.persistedState is not possible any more.

My suggestion would be to:
a) add @PersistState annotation to ui.di
b) call it in the ContributedPart renderer in disposeWidget

Please not this make it work a bit different than in 3.x where the saveState was called on Workbench shutdown only which always bugged me there already.

Comment 1 Thomas Schindl

2012-02-09 11:01:48 EST

Created attachment 210806 [details]
Annotation

Comment 2 Thomas Schindl

2012-02-09 11:03:57 EST

Created attachment 210807 [details]
Modification to PartRenderingEngine

Comment 3 Thomas Schindl

2012-02-10 04:22:23 EST

> b) call it in the ContributedPart renderer in disposeWidget
> 

Better position is in the PREngine

Comment 4 Thomas Schindl

2012-02-10 04:23:42 EST

Any feedback on the API and functional spec would be appreciated

Comment 5 Brian de Alwis

2012-02-10 22:24:14 EST

Is @PersistState really different from @Persist?

Perhaps @PreDestroy should be fixed to happen before the widgets a destroyed?

I'm wondering if the contribution object should be conceptually considered as part of the rendering, and should be keeping the model up to date anyways.

Comment 6 Thomas Schindl

2012-02-11 03:06:54 EST

Yes - it differs a lot from @Persist

@Persit == Persit content
@PersitState == Persist UI-state e.g. scrolling position, ...

I'm not sure we can dispose the context before the widget gets destroyed.

Comment 7 Thomas Schindl

2012-02-13 11:21:39 EST

Created attachment 210922 [details]
revised patch

Patch to execute the save before the dispose happens.

@Brian: I don't think we can use @PreDestroy because at the moment the context is destroyed all services have are unjected, widgets destroyed (by going through the renderers), ... . @PreDestroy can guarantee that the widget that got injected is not already disposed at the moment the context is destroyed whereas @PersistState does this.

We could though discuss the naming of the annotation my PersistUIState is better?

Comment 8 Thomas Schindl

2012-02-13 12:23:43 EST

We decided to go with @PersistState - we also discussed if this could be solved using events but thought @PersistState aligns nicely with @Focus and @Persist so that it makes sense to use it's own annotation.

We also discussed if @PreDestroy could would be the correct callback but when creating the Part we do:
* Create Context
* Create Widget
* Create PartObject

the opposite should be done on tear down so @PreDestory is not the correct callback.

The commit is http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f2a8ce2a9c2725653391ee3326262a984a9fa896

Comment 9 Paul Webster

2012-02-13 12:42:54 EST

(In reply to comment #7)
> Created attachment 210922 [details]
> revised patch
> 
> Patch to execute the save before the dispose happens.
> 
> @Brian: I don't think we can use @PreDestroy because at the moment the context
> is destroyed all services have are unjected, 

I'll just note that during @PreDestroy the context has not been destroyed, and I believe it is called before any of the services are uninjected from the object.

PW