You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most FDC3 Desktop Agents (aka Containers) support the ability to load a layout (a set of applications placed at certain positions on the screen) and the matching save layout request. There may be used defined layouts and system defined ones.
This proposal ignores the requirement to track window positions and start/stop applicatons. Desktop Agent can provide this functionality. This proposal defines additions to the API to allow FDC3 Applications to provide their internal state to be included in the save layout and restored during the load layout.
The scope of the internal state will vary from application to application but will include things like view type, filters, sort orders etc.
it may also include selected items like a trade, an instrument or a contact, but this requires further discussion.
For example:
A layout may contain windows that are showing a client, their portfolio and some information on a selected stock. Say the three windows are all set to the same channel, and the desktop agent allows the user to save the layout.
Each application should be presented with an API for making its state available (during the save request) and then receiving that state during the load layout state. From an FDC3 PoV the state would be a blob (assume JSon) and it's format would be application speciic.
If this use case is adopted there are at least two API' styles that can be used for saving the state. Either an Async call which the desktop agent can invoke to request the state on demand for an FDC3 application, or a requirement for the applications to publish any changes to their state to the Desktop Agent.
I have a preference for requesting state on demand, but maybe we should support both styles. Although the 'push state' does require FDC3 to agree a standardised instance identifier.
The text was updated successfully, but these errors were encountered:
lspiro-Tick42
changed the title
Add save and restore state calls - so apps can participate in save and restore layout calls
Add save and restore state API calls - so FDC3 apps can fully participate in save and restore layout
May 10, 2021
Balance of opinion at Standard WG Meeting - Oct 28th, 2021 #481 was that we should proceed with further discussion, but as an optional part of the specification (MAY)
Proposals to be raised or further commentary on issue before adding to a future meeting agenda.
Enhancement Request
Use Case:
Most FDC3 Desktop Agents (aka Containers) support the ability to load a layout (a set of applications placed at certain positions on the screen) and the matching save layout request. There may be used defined layouts and system defined ones.
This proposal ignores the requirement to track window positions and start/stop applicatons. Desktop Agent can provide this functionality. This proposal defines additions to the API to allow FDC3 Applications to provide their internal state to be included in the save layout and restored during the load layout.
The scope of the internal state will vary from application to application but will include things like view type, filters, sort orders etc.
it may also include selected items like a trade, an instrument or a contact, but this requires further discussion.
For example:
A layout may contain windows that are showing a client, their portfolio and some information on a selected stock. Say the three windows are all set to the same channel, and the desktop agent allows the user to save the layout.
Each application should be presented with an API for making its state available (during the save request) and then receiving that state during the load layout state. From an FDC3 PoV the state would be a blob (assume JSon) and it's format would be application speciic.
If this use case is adopted there are at least two API' styles that can be used for saving the state. Either an Async call which the desktop agent can invoke to request the state on demand for an FDC3 application, or a requirement for the applications to publish any changes to their state to the Desktop Agent.
I have a preference for requesting state on demand, but maybe we should support both styles. Although the 'push state' does require FDC3 to agree a standardised instance identifier.
The text was updated successfully, but these errors were encountered: