Save view settings on exit to view_settings.json

[annapurna-gupta]

Save and Restore View Configurations

• Currently: A view configuration in MSS includes multiple windows with complex settings. Currently, these settings are lost after the user closes the application and recreating them every time is tedious.
• Improvement: The goal is to save and restore these configurations locally and on the server, so that users can easily continue where they close the application or login in another device.

Details

Store and Restore View Configuration Locally and on Server

The msui_mainwindow currently manages all open views but does not retain their states when the application is closed. This proposal introduces a way to capture and restore view settings upon exit and re-login, enhancing user experience by preserving configurations across sessions and devices.

1.1 Proposed Changes for Local Flight Tracks

Create a New File: mslib/utils/view_restoration.py

This file will handle the core logic for saving, loading, and validating view configuration settings using a local JSON file (view_setting.json).

The key changes proposed include:

■ A way to capture view states on exit:

• Override closeEvent() in msui_mainwindow.
• When the user closes the application, the current state of all open views (e.g., flight path, window size and position, active widgets) is captured.
• This data will be passed to a function in view_restoration.py to be saved in view_setting.json.

■ A way to save settings in view_setting.json file:

• View settings will be stored under a unique user ID key in the shared JSON dictionary.
• The data will be validated before saving to ensure it's complete and well-structured.
• A function in view_restoration.py will write the captured view configuration into the JSON file.
• If settings already exist for a user, they will be overwritten with the latest data.

■ A way to load settings for user:

• If the user enables the restore_views option:
  • The system checks whether view_setting.json exists.
  • If it exists, it looks for the user's data using their unique user ID.
  • If found, the view state is restored.
  • If not found, the application falls back to the default configuration.

■ A way to validate the settings before saving to JSON file:

• Before saving to the JSON file, view_restoration.py will validate the structure and completeness of the data.
• Required fields (e.g., flight path, window position, widgets, etc.) must be present.
• This prevents saving incomplete or broken states.

Adding Option restore_views

A new configuration option, restore_views, will be introduced to allow users to control whether the application should restore the previously saved view configuration on startup.

• If restore_views is enabled:

  • The system will check for the presence of the view_setting.json file in the user's configuration directory.
  • If the file exists and is valid, then the system will search for the user's saved view settings within the file.
  • If found, the settings will be loaded and applied automatically (e.g., window sizes, open views like FlightTrack, their positions, etc.).
  • And if the user-specific settings are not found, the application will fall back to default settings.

• If restore_views is disabled:

  • The application will ignore the view_setting.json file (even if it exists).
  • It will start with the default layout and view configuration.

Proposed restore_view Option

This button allows users to quickly restore their previous session’s layout using saved settings from view_setting.json.

1.2 Proposed Changes for Operation (Server)

Extend Database (mslib/mscolab/models.py)

• Extend the database (mslib/mscolab/models.py) to include a new ViewSettings table for persistent storage of view configurations.
• Storing configurations in the database ensures they are retained and accessible across sessions and devices.

Implement Server API Endpoints

The API will act as a bridge between the client and the database to enable saving and restoring view configurations.

The key changes proposed include:

■ A way to save view configuration:

• The client will send view configuration to the server via POST request.
• The server will validate the data and save it to the viewSetting table in the database.

■ A way to restore configurations:

• The client sends a GET request to fetch stored view settings.
• The server retrieves configurations from ViewSettings and returns them to the client.

[ReimarBauer]

see comments

after stable to develop is merged the github version test is fixed. the test with the timeout is a common problem on testing we not have figured.

the linters shows some changes needed too

[ReimarBauer]

@annapurna-gupta This adds support for the restore_view config option. We should probably change the PR title before merging – it currently sounds like something happens when the app closes.

[annapurna-gupta]

@annapurna-gupta This adds support for the restore_view config option. We should probably change the PR title before merging – it currently sounds like something happens when the app closes.

Yeah, I just changed the title — is it okay now?

[ReimarBauer]

do you plan the "storage part" of SideView etc. to become added in this PR too?

[annapurna-gupta]

do you plan the "storage part" of SideView etc. to become added in this PR too?

I thought it should only store and restore the top view settings — should it also include side, table, or linear views?

[ReimarBauer]

do you plan the "storage part" of SideView etc. to become added in this PR too?

I thought it should only store and restore the top view settings — should it also include side, table, or linear views?

Yes, we need this for all views.

[ReimarBauer]

Here’s another idea: Comparing this to the tutorial mode , where I use the objectName to generate images that I can then uniquely associate with data, could we perhaps store the names? Later those can then re-associate data with them.
This may allow for a standardized get_settings function.

[ReimarBauer]

please update your develop branch on github and then rebase to develop.

or rebase to develop on your remote, see https://mss.readthedocs.io/en/stable/development.html#setting-up-a-git-remote

[ReimarBauer]

see comments

[ReimarBauer]

maybe It would be better to use a filename parameter and use a name.

you maybe need an information in the view_settings.json to compare with the data of the waypoint table. e.g. path, url, ..

[ReimarBauer]

it is maybe better to save to a filename so that flightpath file exists and to avoid storing anything for the current default "new flight track (...)"

Because when you do use it for temporary data at the moment someone hitting the create new button and having something in the json file like,

{
  "new flight track (2)": {
    "global": {
      "mss_version": "10.1.0",
      "flight_track_name": "new flight track (2)"
    },
    "views": [
      {
        "view_type": "topview",
        "view_id": "view_topview_0"
      },
      {

windows gets pushed on him

Changes on the behaviour should be done in the next PR

[ReimarBauer]

hmm, this makes an os.path string from the Path, was there a problem solved by the change, which one?

[ReimarBauer]

on the terminal I see sometimes

ERROR: Failed to get settings for topview (id: unknown): 'url'

[annapurna-gupta]

on the terminal I see sometimes

ERROR: Failed to get settings for topview (id: unknown): 'url'

looking on it

[matrss]

This is effectively a no-op, mswms_server == server_url. You don't have to parse the URL if you don't need its parts. xref: #2831 (comment)

[ReimarBauer]

further work will be done in a new PR

[ReimarBauer]

send it to your branch please

[ReimarBauer]

base branch changed