Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Save/restore workspace on close/open app #565

Open
jakoss opened this issue Oct 13, 2023 · 5 comments
Open

[Feature request] Save/restore workspace on close/open app #565

jakoss opened this issue Oct 13, 2023 · 5 comments
Labels
enhancement New feature or request
Milestone

Comments

@jakoss
Copy link

jakoss commented Oct 13, 2023

I would love bruno to save my workspace when i close it and restore it when i come back. By workspace i mean tree state (which leaves are collapsed/expanded), opened tabs and chosen environment. Right now when i come back to bruno i have to click my way through everything to just get back to work

@majkinetor
Copy link

majkinetor commented Oct 17, 2023

We also need to have saved:

  1. Sidebar width ([User Experience] Persist sidebar width to preserve application restarts #635)
    2. It makes sense to include toggle to be completely hidden
  2. Window state (Electron app doesn't store window state/size #451, Fix: save window maximized state #536)
  3. Last used tab within request

I don't think this should be put into any of the existing files because different users will have different settings. It makes some sense this to go into the repository though, so if one works alone he can sync his state on different machines, but could be .gitignored in team scenario. Or better, create window profiles and make this starting state a special "current" profile.

@Andreas-Schoenefeldt
Copy link
Contributor

Please also the selected environment per collection (#899)

@sanjai0py sanjai0py added the enhancement New feature or request label Jul 2, 2024
@helloanoop
Copy link
Contributor

This feature requires careful design considerations due to its complexity.

First, we need to document the various parts of the state that need to be memoized. Examples include:

  • Opened Tabs
  • Selected Environment
  • Sidebar state (e.g., whether a folder tree is collapsed)

Additionally, we need to consider the data flow in Bruno. Since the filesystem represents the state, we should maintain the memoized state of the app within the Electron layer using electron-store. When the application launches, this state will be published to the app.

@PDDStudio
Copy link

PDDStudio commented Jul 15, 2024

Hello,

I was looking into contributing (parts of) this feature and would like to give some thoughts, and ideas and ask questions to refine the feature further.

Current state:

  • Only last opened collection(s) are stored in last-opened-collection.js Store.
  • Paths are loaded (if valid bruno collection) on startup and the collection becomes available in the sidebar (collapsed)
  • No last open tabs or last active environment is saved. Also the Sidebar width is not saved.

Proposal:

  • Extend the Store that saves 'last opened' configurations (e.g. rename it into last-opened-config.js)
  • Store
    • last opened collections, open tabs per collection, active tab
    • sidebar width & sidebar expanded items
    • active environment
  • On startup, load the config as done before (or merge with defaults if not configured yet) and notify relevant components

Example config object:

  {
     "latOpenedConfig": {
       "activeEnvironment": "/path/to/env or uuid?",
	   "activeTab": "uuid",
       "collections": [
         {
           "path": "/path/to/collection",
           "openTabs": [ "uuid1", "uuid2" ]
         }
       ],
       "sideBarWidth": 500,
       "sideBarExpandedItems": [
         "collection-uuid1",
         "folder-uuid2",
       ]
     }
  }

I would like to gather feedback on this approach or if there's something you would do differently.

A question from my side would be - from my current understanding - the UUIDs used for the tabs in the UI are generated on the fly.
For the persistence to work we would need some kind of unique identification for each request and thus migrating the uuid to be part of the request schema (inside the bru file) would be the best fit I've come across so far.

Maybe you have a different approach in mind that would make solving this issue easier without adding too much overhead to the implementation?

Other than that, looking for feedback and suggestions on my proposal

@PDDStudio
Copy link

@helloanoop @sanjai0py any thoughts from your side on my proposal?
What do you suggest would be a good way to get this started?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants