Store and restore active-project-path explicitly
Fixes #1471
- Add a new setting to schema and make source of truth
- Bind setting to GitManager property
- Only ProjectChooserButton changes the active project (except GitManager as fallback)
- Keep existing global search behaviour by managing the global search path separately.
- Remove some unused or unnecessary related code.
The interface no longer tries to second-guess the active project based on user actions except for selecting (or reselecting) the active project through the chooser.
Global search continues to be carried out in the selected document's project (if it exists), falling back to the active project and ultimately the document itself.
Other actions that use the default action target like "New Branch" will now use the active project as shown in the ProjectChooserButton (and terminal path) regardless of which document is focussed when invoked with the keyboard. These action invoked with a folder context menu will target that folder regardless of the active project. This behaviour can be revisited if required.
Another side effect of this is that the active project is synchronised across open windows. May have to store active project on a per window basis?
@danirabbit Hmm, OK. I was trying to make the "active project" more stable and avoid conflict between what the terminal build directory is and what the active project is. May have to rethink the global search. It is not clear what to do if the user opens documents in more than one project at a time. I guess the search should be done in the project associated with the currently focussed document? I am reluctant to have the active project keep switching depending on which document is focussed! The active project, in my mind, is the one that is being developed and built. Agreed you might want to have documents from other projects open for reference but that does not change the focus of development.
@danirabbit I have tried to address your concerns by decoupling the "active project path" from the "global search path". The main issue now is whether you want to be able to have different active projects in different windows. This could be useful I guess but would require having separate GitManager instances for each window. Only one of the window would be restorable at the moment.
Converting to draft while fixing a bug in choosing active projects with same beginning of name.
@danirabbit I would be grateful if you would reconsider the revised version of this PR. The project-wide search now follows the project associated with the focussed document as before, which I believe was you main concern. I have some uncertainty about what to do with "project" folders that are not git repos but this is probably not blocking as it pre-exists. Do we need to distinguish these as far as setting the terminal path or project button for example. At present in this PR the context menu for the project folder does differ but it would be simpler if it didn't so I am happy to revert that.