Description
Migrated from https://bugs.eclipse.org/bugs/show_bug.cgi?id=572730:
Christoph Laeubrich CLA Friend 2021-04-09 07:16:15 EDT
If views show complex data it might be a good choice to actually disable certain functions if the part is not visible (e.g. another tab is hiding it).
The proposal is to have @suspend / @resume annotations that behave the following way:
- whenever a part is minimized or a tab is become hidden (e.g. another one is selected) a method annotated with @suspend is called.
- whenever a part that previously was minimized or hidden (e.g. in a ctab) a method annotated with @resume is called.
this would allow to suspend/pause for example side effects or tracker.
[tag] [reply] [−] Comment 1 Lars Vogel CLA Friend 2021-04-09 07:39:41 EDT
Wim, didn't you do something like this in the past?
[tag] [reply] [−] Comment 2 Wim Jongman CLA Friend 2021-04-09 09:14:45 EDT
(In reply to Christoph Laeubrich from comment #0)
If views show complex data it might be a good choice to actually disable
certain functions if the part is not visible (e.g. another tab is hiding it).The proposal is to have @suspend / @resume annotations that behave the
following way:
- whenever a part is minimized or a tab is become hidden (e.g. another one
is selected) a method annotated with @suspend is called.- whenever a part that previously was minimized or hidden (e.g. in a ctab) a
method annotated with @resume is called.this would allow to suspend/pause for example side effects or tracker.
That is a nice idea. I always call the framework to know if I am visible in a selectionchanged situation which is boilerplate @suspend could take away.
For menus, we currently have: @AboutToHide/Show
I think the @resume, although slightly different, is covered by @Focus?
(In reply to Lars Vogel from comment #1)
Wim, didn't you do something like this in the past?
I did but using existing API ^^
[tag] [reply] [−] Comment 3 Christoph Laeubrich CLA Friend 2021-04-09 09:23:50 EDT
(In reply to Wim Jongman from comment #2)
That is a nice idea. I always call the framework to know if I am visible in
a selectionchanged situation which is boilerplate @suspend could take away.
The bad thing is that one don't get notified afterwards when the view becomes visible again. Thus an @resume could recover from that state then without the need to have special code for it.
For menus, we currently have: @AboutToHide/Show
I think the @resume, although slightly different, is covered by @Focus?
@Focus is different I think as for example I can have two views, both are visible, every time I select one of them it revives the @Focus
@PostConstruct on the other hand is only called when the view is created the first time (what already has some logic to not create views that are currently not visible)
@resume would be something in between, notify the view that is has become visible again (without close/recreate) it.
[tag] [reply] [−] Comment 4 Wim Jongman CLA Friend 2021-04-09 09:27:26 EDT
+1
[tag] [reply] [−] Comment 5 Rolf Theunissen CLA Friend 2021-04-19 04:05:40 EDT
Speaking of existing API, in the E3 implementation there must have been lots of though on the lifecycle of a Part.
Please consider all lifecycle events that are defined in IPartListener/IPartListener2 (and the E4 IPartListener) and how these map to annotations on E4/POJO, if they are relevant.
In PartServiceImpl activate, you can see that activate/bringtotop/focus all have slightly different semantics (a part can be brought to top without being activated, when a part is activated it can optionally get focus).
Also, I see that there are the E4 UI life cycle events UIEvents.UILifeCycle.BRINGTOTOP and UIEvents.UILifeCycle.ACTIVATE, which are related too.
Clearly defined and documented lifecycle stages of parts, with mapping on E3/E4 events and annotations would be helpful.