Describe the solution you'd like
PR #10327 makes the desktop runtime remember the last directory a native file dialog visited, so that dialogs stop reopening in Downloads after the Electron 38 change removed the implicit behaviour. It keeps a single lastVisitedDirectory key in the runtime config store, written by both the open and the save handlers, which means Backup, Restore, ERD saves, the storage manager and everything else share one remembered folder: save an ERD somewhere and the next backup starts in the same place.
It would be nicer to remember a folder per purpose, so that backups keep returning to wherever backups go whilst ERD saves keep returning to wherever diagrams go, rather than each dialog inheriting whatever the previous one happened to touch.
Describe alternatives you've considered
Leaving it as one global folder, which is what #10327 does and what most people may well want, since it already fixes the reported problem and needs no per-caller changes.
Additional context
Suggested by @razzeee in #10327 (comment).
The extension looks straightforward rather than a rework, because every native dialog funnels through FileManagerModule.showNative() in web/pgadmin/misc/file_manager/static/js/FileManagerModule.jsx: a context key could be passed through window.electronUI.showSaveDialog/showOpenDialog and the preload shims in runtime/src/js/pgadmin_preload.js, and the store keyed per context, falling back to the current global value whenever a context has nothing saved yet.
The part that needs the work is the callers. params currently carries only dialog_type, which is one of create_file, open_file, select_file or select_folder, and that describes the shape of the dialog rather than what it is for, so each call site would have to start passing a purpose of its own before there is anything to key on.
Describe the solution you'd like
PR #10327 makes the desktop runtime remember the last directory a native file dialog visited, so that dialogs stop reopening in Downloads after the Electron 38 change removed the implicit behaviour. It keeps a single
lastVisitedDirectorykey in the runtime config store, written by both the open and the save handlers, which means Backup, Restore, ERD saves, the storage manager and everything else share one remembered folder: save an ERD somewhere and the next backup starts in the same place.It would be nicer to remember a folder per purpose, so that backups keep returning to wherever backups go whilst ERD saves keep returning to wherever diagrams go, rather than each dialog inheriting whatever the previous one happened to touch.
Describe alternatives you've considered
Leaving it as one global folder, which is what #10327 does and what most people may well want, since it already fixes the reported problem and needs no per-caller changes.
Additional context
Suggested by @razzeee in #10327 (comment).
The extension looks straightforward rather than a rework, because every native dialog funnels through
FileManagerModule.showNative()inweb/pgadmin/misc/file_manager/static/js/FileManagerModule.jsx: a context key could be passed throughwindow.electronUI.showSaveDialog/showOpenDialogand the preload shims inruntime/src/js/pgadmin_preload.js, and the store keyed per context, falling back to the current global value whenever a context has nothing saved yet.The part that needs the work is the callers.
paramscurrently carries onlydialog_type, which is one ofcreate_file,open_file,select_fileorselect_folder, and that describes the shape of the dialog rather than what it is for, so each call site would have to start passing a purpose of its own before there is anything to key on.