Draft Idea: Thinking more about workspaces in GRASS GUI

[lindakarlovska]

I was thinking about it more and I generally like the idea from #3113 where workspace are part of a mapset - I like it from the point of a user that I will switch to a mapset and the workspace will be automatically created for me. What I like less is thinking about it from the view of storage - I do not like that the data and the technical GUI configuration file is mixed in one directory, though I don’t yet have a perfect solution either.

I think it would make sense to store workspaces on default in the new configuration directory ~/.grass8/workspaces/ and show them in a separate Workspaces tab - also creating its own pane for Workspaces would be not just to manage workspaces more easily, but also to raise their visibility and encourage users to take advantage of them.

I put the idea into short presentation: https://docs.google.com/presentation/d/1cPsE971Iis9WzRRwtR0OoUgZJRcVEmgNN6GjGzUCmUk/edit?slide=id.g3367653f5f2_0_49#slide=id.g3367653f5f2_0_49.

I think that the idea in #3113 is not against what is in the presentation, I actually believe they could complement each other quite well (though it would definitely need some thinking and coordination). That’s why I’m sharing this here — to open it up for discussion and see if others feel similarly or have additional ideas.

[wenzeslaus]

I think the project can store data, computational regions, labels, and yes even the GUI state. I still favor something like #3113 where workspace is integrated into the project, and potentially completely hidden in the sense that there is less concepts to grasp.

Project is the main thing user should focus on

Projects are now naturally the main thing for a user to interact with, with mapsets playing a role of organizing the data further if needed. For desktop GUI users, GUI is in front of them, so GUI can nicely just fall into the same place, i.e. project.

Quoting myself in #3121 (Rename location to project):

We are choosing project as the new name because:

1. Location is the main structure used for organizing data in GRASS GIS. Project is what software packages often use to organize what they work with.
2. The word project should emphasize that this is the level in the hierarchy to focus on. The other two levels might be useful, but this one is crucial.
   ...
   What about GUI workspaces? While the GUI workspace files share a lot in common with projects in other software, the parts they share are state of the GUI. The workspaces in GRASS GIS don’t have the central role project files have in other software.

Projects already store non-data

We adopted the name project, considering that is it is catch-all term, and in fact, projects already store things which are not data.

Myself again now from #2993 (Minimal changes to rename...):

A GRASS location (or mapset) does represent the state of what the user was doing in a sense that it has all the data you were working with, history of what you were doing, current computation extent and resolution, default extent, bookmarked extents (spatial bookmarks aka saved regions), associated styles when stored as color tables, labels for cartography (v.label, d.label), links to external data, even your selected CRS.

One may argue that the state of the GUI is missing [in the GRASS project]. I would agree. I think what is now a workspace file would make most sense as part of a mapset (I'm thinking that since I saw the low uptake of workspace file with stored mapset path and the much more successful data management panel).

While projection or CRS is an import part of what location is in GRASS GIS, both projection and CRS refer to something completely different than data storage and what locations do is storing data. They store them in a particular way which involves data format and CRS, but they are more than just data storage, they also store much of the information users generates when working with the software.

Mixing data and state is common elsewhere

Given this is about desktop GUI and related to management of data, comparison with ArcGIS and QGIS may be helpful:

About ArcGIS and QGIS from #2993:

The ArcGIS Pro project files are grouped together with actual data storage, not just views or links to data.

While QGIS project does not store data, it stores auxiliary data and it can be stored inside a GeoPackage with the data (so go as far as saying [QGIS] GeoPackage Project).

In cases of ArcGIS and QGIS, actual data storage can be part of the project, so it is not just purely state of the GUI. For wxGUI, the workspace file referred originally to state of the GUI (some windows, added layers, d-command styling, 3D) and now it includes also path to mapset.

The word workspace is used in ArcGIS:

Tools that honor the Current Workspace environment use the workspace specified as the default location for geoprocessing tool inputs and outputs. ... In ArcGIS Pro, the default value for the Scratch Workspace and Current Workspace environments is the project default geodatabase.

So the two closet things we have are what is currently called mapset (not location!) and current working directly (pwd, os.getcwd(), getwd()).

And QGIS documentation uses that to refer to whatever sort of the state of the GUI thing:

QGIS can save the state of your workspace into a QGIS project file using the menu options Project ► Save or Project ► Save As….

That would be the GUI workspace file, except that QGIS project can have associated external data like Shapefile on the disk and the workspace file cannot. However, GRASS GIS can do it in a location, or more precisely in a mapset (v.external, r.external).

...so maybe there is not a clear distinction between data and non-data parts of projects. v.external and r.external linked data would be how things are added to a GUI-driven "project" file in other software, in GRASS, it is on the same level as data already.

[veroandreo]

I like the idea of having a dedicated panel or tab in the GUI to list and manage workspaces; this would improve usability and encourage users to make better use of workspaces, well, discover they exist! :)

I personally prefer the concept proposed in #3113, where the workspace remains tied to a mapset. From a user perspective, this feels more natural and organic: when I switch to a mapset, I would expect the relevant workspace to be automatically loaded, or have the chance to select the one I want from a panel - I'm thinking of various workspaces per mapset displaying different sets of maps, without needing to browse a separate list disconnected from the project structure.

[YannChemin]

I like the idea of having a dedicated panel or tab in the GUI to list and manage workspaces; this would improve usability and encourage users to make better use of workspaces

That, I would use daily. I need to switch half a dozen projects' mapset in a day, already the "double-click mapset" to switch is great in the GUI, but I still need to load my workspace each time again.

[lindakarlovska]

I like the idea of having a dedicated panel or tab in the GUI to list and manage workspaces; this would improve usability and encourage users to make better use of workspaces, well, discover they exist! :)

I personally prefer the concept proposed in #3113, where the workspace remains tied to a mapset. From a user perspective, this feels more natural and organic: when I switch to a mapset, I would expect the relevant workspace to be automatically loaded, or have the chance to select the one I want from a panel - I'm thinking of various workspaces per mapset displaying different sets of maps, without needing to browse a separate list disconnected from the project structure.

I was just thinking more about this and would like to discuss it further at the PSC meeting on Friday. I agree with the proposal in github.com//pull/3113 – it makes complete sense to store workspaces as part of the mapset and to automatically create a workspace if it doesn’t already exist there. From the storage perspective, I also agree with @wenzeslaus that mixing data and non-data elements is perfectly fine.

The main concern is that there’s currently no central overview of saved workspaces, so users may easily lose track of them. The proposed Workspace pane would help manage this, and I agree with @vero that it would even help users discover that a workspace concept exists in GRASS and is useful :-).

I’ve created a simple mockup to better illustrate the idea. The mockup is implemented using the wx.ListCtrl widget, but it is mostly illustrative — the important part is the description and concept outlined below:

The pane would show a list of workspaces dedicated to the current mapset. Several functions would be available either via a context menu on each list item or through a toolbar, specifically:

- New – Create a new workspace
- Save – Save the workspace
- Delete/Remove – Remove from the list (optionally also delete from disk)
- Set active – load the workspace (could be done also by double clicking on the workspace node)
- Duplicate
- Rename
- Info – Open a small dialog with brief info about what is stored within the workspace
- Filter by workspace name
- Refresh

For each workspace list item, it could display:

- Status: Not saved, Saved – this could mean having a refresh button or automatic refresh every few seconds
- Modified date
- Path – could be shown as a tooltip when hovering over the workspace name

The currently active workspace would be highlighted, ideally in bold, similar to how database/location/mapset are shown in the Data tab. External file changes probably wouldn’t be handled initially, or could potentially be addressed via a watchdog mechanism...?

This is an initial draft proposal, so please feel free to provide feedback and share any additional ideas on how this could be improved :-).

[lindakarlovska]

Yesterday, we discussed the Workspace topic with @petrasovaa and @wenzeslaus and finally decided not to overcomplicate it. The idea is to always have one workspace per mapset – this way, the workspace logic will remain mostly hidden from the user.

Users would still be able to create and load their external workspace files. However, at the same time, there will always be an internal GUI state (or “mapset GUI settings” – we don’t necessarily need to call it a workspace) that benefits from the existing workspace mechanism.

This internal GUI state linked to the mapset does not need to be displayed anywhere in the GUI – it will simply exist in the background and load automatically whenever the given mapset is activated.

Any opinions or counterarguments on this?

[marisn]

I assume that means auto-loading on GUI startup. You'll have to code in really good way to handle cases when workspace file is broken or made with a really old version (think – try to open GUI in a mapset that hasn't been used in 10 years).