OSGeo
wxGUI: Make GUI workspace part of mapset
- Automatically create workspace file in a mapset when GUI is notified about the change if it does not exist.
- If workspace exists in a mapset, open it.
- If workspace does not exists and but the previous mapset was in the same location, it keeps the open mapdisplays as before.
- The updates to workspace are not saved automatically (in time interval, before switch, or at exit), so user needs to save the workspace (Ctrl+S) in order to keep the state.
This is a proof of concept and not meant for merging. If someone wants to pick it up, I'm more than fine with that.
A possible extension or variation of the proposed change is to explicitly support more than one workspace file directly in the mapset directory. Allows for more than one workspace per mapset, but does not require much additional logic or understanding as a separate subdirectory in the mapset directory. Here is a whiteboard after discussion with @veroandreo (green lines mark the new parts for workspaces):
I'm not quite sure if it makes sense to combine mapsets and workspaces in the same place. The Data tab is really just about data, while a workspace represents the state of the GUI. What if, instead of going in the direction of "I have a mapset and I want to see all its workspaces," we think the other way around: "I have a workspace and I want to see its current mapset — and possibly some related info."
I’ve put the idea into a short presentation: https://docs.google.com/presentation/d/1cPsE971Iis9WzRRwtR0OoUgZJRcVEmgNN6GjGzUCmUk/edit?usp=sharing Please feel free to take a look and share your thoughts.
I know this is different from the direction of the current PR, but since it hasn’t been merged yet, I thought now might be a good time to step back and consider things from another perspective.
I'm not quite sure if it makes sense to combine mapsets and workspaces in the same place. The Data tab is really just about data, while a workspace represents the state of the GUI. What if, instead of going in the direction of "I have a mapset and I want to see all its workspaces," we think the other way around: "I have a workspace and I want to see its current mapset — and possibly some related info."
I’ve put the idea into a short presentation: https://docs.google.com/presentation/d/1cPsE971Iis9WzRRwtR0OoUgZJRcVEmgNN6GjGzUCmUk/edit?usp=sharing Please feel free to take a look and share your thoughts.
I know this is different from the direction of the current PR, but since it hasn’t been merged yet, I thought now might be a good time to step back and consider things from another perspective.
Maybe move this to GH discussion, it might get lost here.
I'm not quite sure if it makes sense to combine mapsets and workspaces in the same place. The Data tab is really just about data, while a workspace represents the state of the GUI. What if, instead of going in the direction of "I have a mapset and I want to see all its workspaces," we think the other way around: "I have a workspace and I want to see its current mapset — and possibly some related info." I’ve put the idea into a short presentation: https://docs.google.com/presentation/d/1cPsE971Iis9WzRRwtR0OoUgZJRcVEmgNN6GjGzUCmUk/edit?usp=sharing Please feel free to take a look and share your thoughts. I know this is different from the direction of the current PR, but since it hasn’t been merged yet, I thought now might be a good time to step back and consider things from another perspective.
Maybe move this to GH discussion, it might get lost here.
I'm not quite sure if it makes sense to combine mapsets and workspaces in the same place. The Data tab is really just about data, while a workspace represents the state of the GUI. What if, instead of going in the direction of "I have a mapset and I want to see all its workspaces," we think the other way around: "I have a workspace and I want to see its current mapset — and possibly some related info."
I’ve put the idea into a short presentation: https://docs.google.com/presentation/d/1cPsE971Iis9WzRRwtR0OoUgZJRcVEmgNN6GjGzUCmUk/edit?usp=sharing Please feel free to take a look and share your thoughts.
I know this is different from the direction of the current PR, but since it hasn’t been merged yet, I thought now might be a good time to step back and consider things from another perspective.
I'm not quite sure if it makes sense to combine mapsets and workspaces in the same place. The Data tab is really just about data, while a workspace represents the state of the GUI. What if, instead of going in the direction of "I have a mapset and I want to see all its workspaces," we think the other way around: "I have a workspace and I want to see its current mapset — and possibly some related info." I’ve put the idea into a short presentation: https://docs.google.com/presentation/d/1cPsE971Iis9WzRRwtR0OoUgZJRcVEmgNN6GjGzUCmUk/edit?usp=sharing Please feel free to take a look and share your thoughts. I know this is different from the direction of the current PR, but since it hasn’t been merged yet, I thought now might be a good time to step back and consider things from another perspective.
Maybe move this to GH discussion, it might get lost here.
I have put it here: https://github.com/OSGeo/grass/discussions/5916.
Following https://github.com/OSGeo/grass/discussions/5916#discussioncomment-14045240 - just thinking about how to easily distinguish external workspaces and the internal workspace linked to mapset. @wenzeslaus What about just making it as the hidden file? E.g. instead of mapset_name.gxw making .mapset_name.gxw ?
Discussed at PSC meeting, my take:
We can ask: Do you want to save it?
- Yes, and do this always
- Yes, but only this time
- No, and never do this
- No, this time