Summary: | @Suspend / @Resume annotations | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Christoph Laeubrich <laeubi> |
Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | Lars.Vogel, marco, rolf.theunissen, tom.schindl, wim.jongman |
Version: | 4.20 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: |
Description
Christoph Laeubrich
2021-04-09 07:16:15 EDT
Wim, didn't you do something like this in the past? (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 ^^ (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. +1 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. |