The old startup screen is still used when the last used mapset is not in usable state

[lindakladivova]

The Issue works as a discussion for how to start GRASS GIS when the last mapset is not in a usable state.
So far, we have worked with two proposals of GRASS GIS start for common users (we do not talk about first-time users, here the situation is complete - GRASS offers demolocation with first-time info bars for first-time users).

Describe the solution you'd like
We would like to entirely remove the old startup screen.

Describe alternatives you've considered
So far, we were thinking with Vashek about two options for how to proceed:

Proposal 1:

Proposal 2:

Additional context
This issue has been already a bit discussed in #1208.

here is the current conversation:

HuidaeCho
@lindakladivova @wenzeslaus I think I'm missing something here. What is the rationale behind all this workflow for creating an unrequested location and mapset? If a last used mapset is in an unusable state (not clear what it means... because another user is already using it? Or has GRASS crashed before leaving the mapset in an "unusable" and unfixable state?), shouldn't we try to fix the mapset instead of creating a new default location and mapset silently? What if the default mapset in the default location becomes "unusable"? Create yet another default mapset 2 in that same default location or a default mapset in a new default location 2? And keep creating a new mapset whenever the last used default mapset becomes unusable?

The last step in yellow is also unclear. Does it create a new default location first and then what does it suggest to do in "To continue..."? If the user continues, what happens? If not, then what? Continue to switch to the last used mapset (is it possible now?)? Not continue to start in the just created default mapset?

Other than the workflow, moving code for non-GUI functionalities to grass.app looks fine. BTW, grass.app sounds too general. What is this submodule mainly for? If for the "main GRASS GIS executable" (startup script?), I think grass.startup or grass.init would be more appropriate.

lindakladivova
Well, we are still not sure how to solve the case when the last mapset is not in the usable state. The notion is that the behavior should be consistent. In this proposal, if the last used mapset is not in the usable state (yes, GRASS crashed or another user is using it) we use the default location (demolocation) as workarounds in order to not use the old startup screen anymore. The GRASS GIS offers the default location and informs the user about that in the Info Bar which has the same form as the one used newly for every first-time user when starting GRASS. The text of the Info Bar is in the proposal in a yellow box. It has a character of advice because the user may be surprised why he is in demolocation, so the Info Bar explains why and advises what to do next.

As you have noted, there can be a case when the default mapset in the default location is in the usable state.. In this case, we can create the user mapset because we need "some" mapset, and show the Info Bar to the user as well.

Let's discuss about it :-) I believe we can come up with a better solution. I also created a second a bit more complex proposal which takes into consideration the last used location.

However, the disadvantage of the second proposal is that the GRASS GIS startup process would not be consistent. The first solution is always consistent - boot in the demolocation in each non-standard situation and provide the same message in the Info Bar. Another thing about the Proposal 2 is that it presents a new concept, which assumes that the PERMANENT mapset is some kind of default mapset. This would mean incorporating this idea into other segments of GRASS. For example, in the Data Catalog context menu, there should be a possibility to switch to location (its PERMANENT) from the location node.

HuidaeCho
My point is when a mapset becomes unusable, we should advise users how to fix it, not deviate them from their intended workflow. If GRASS crashed and the last used mapset became not startable because of some garbage, most of the case, I think we can fix it programmatically. If not (e.g, broken metadata files let's say), ideally, GRASS should be able to detect which part of metadata is broken and ask the user what's missing and fix it.

If someone else is using the last used mapset, we should give the user options with a warning that someone is using the mapset: 1) just don't start GRASS (maybe, with an email notification when the current user leaves, but it would require a whole different discussion and architecture) or 2) let the user create a new mapset in the last used location (because the user will be able to access data in the last used mapset by tweaking the search path) with her/his choice of a mapset name. In any case, when GRASS supports the last used mapset when no mapset is specified, that means we want to put them in the last used mapset or at least in the last used location, not in a world-wide latlong location in any case. That would be a big surprise for me when I assume that I would fall in the last used mapset in a certain projection (location). Starting in a world location may be fine when there are no locations at all, but still I would ask them if they want it or some other projection.

Trying to create a new default location or mapset can be very tricky because, again, we may be trapped in a loop where we have to keep creating a new mapset or location when the previous default mapset becomes unusable. In the second proposal, I would say the PERMANENT mapset is not meant to be a default mapset. I just feel like it's not a working mapset, but it's more for storing original data in a clean state before any analysis in other mapsets. Maybe, it's just me.

Now, are you planning to implement all this workflow only in the GUI startup? Or is it going to be part of the CLI as well to be consistent? Also, are you going to ask the user location or mapset names before creating them?

[lindakladivova]

@HuidaeCho Ok, as I get it right, you like much more the second proposal. It makes sense but I would note that the state of Data Catalog is now quite straightforward, so it is very easy to create a new location, add a new database etc... - therefore, from my point of view, it is not a big surprise and problem to the user when he will be redirected to the demolocation. But on the other hand, we should try to minimize the number of cases when it happens, I agree with that.

As I remember, this solution was planned for GUI, because we mainly wanted to solve the problem of the old startup screen.

We had the idea that the mapset will be named according to the user name (if not possible to use PERMANENT). We already used this concept - after GSoC the "user" mapset was the part of demolocation. However, in surveys, some people perceived it too confusing so now there is only PERMANENT mapset in demolocation.

Maybe, we will need some startup screen anyway. We wanted to avoid it, but I am also a bit afraid about that loop you have described - keep creating a new mapset or location when the previous default mapset becomes unusable...

What @wenzeslaus think? Do you have any ideas?

[HuidaeCho]

@lindakladivova Please enlighten me what is wrong with the current startup. I think we have to start from there. Do you want to eliminate the barrier between locations and mapsets altogether for casual users (like how the current data catalog works)? Then, why? To attract more non-GRASS users who are hesitant to adopt a new "weird" GRASS paradigm because it's not familiar to them?

[lindakladivova]

@HuidaeCho Yes, partly. I would like GRASS to be more user-friendly.

We have three different situations now:

1. Startup for first-time user
Demolocation and info bar are displayed. No startup screen occurs.

2. Startup in last used mapset if is in the usable state. No startup screen occurs.

3. The last used mapset is not in the usable state - the old startup screen still appears in this special case.

We would like to solve this special case and remove the startup screen - and the aim of our discussion is how to do it, I would prefer not to create another startup screen, I like the way without it...

[HuidaeCho]

@lindakladivova Thanks for the summary. For case 2, we don't have any problems. For case 1... Let's say students share a lab computer. One student has started GRASS once. Other students want to use the same GRASS database location, but they start GRASS for the first time from their account. Windows doesn't allow multiple remote logins, but UN*X does. It becomes case 3 in UN*X now if the first user is using the same mapset, if you agree? If the first user is not using the same mapset, is it case 1 (because it's the first time run from this account, preferred) or case 2 (another user's last used mapset, not preferred because we don't care about other users' last used mapset)? Or they can choose a new GRASS database location to make it our intended case 1 (first time with no locations). So either way, we didn't add any more cases here. It's just more complicated.

For case 3, I would like to create to a new mapset under the last used location always. Mapset name? Either ask the user or last_used_mapset-username. This "-username" suffix gives a hint to other users that it's not for them and we can only hope that they don't use it. What if they still try to use other user's dedicated mapsets (mapset-not_your_username)? Well... stop them and force them to use just "mapset" or create their own dedicated "mapset-username" in case "mapset" is "unusable"? Just don't allow any user in other user's own mapset. Again, this is still a lot of checks and can be problematic in terms of permissions later.

OR, maybe, create a new mapset in the last used location, but add an input textbox where a mapset is in the data catalog so they can type one themselves. Warning message why they need to do it above the catalog of course.

I have another question. Why do you prefer not to create another startup screen? Why do you try to not ask where to start? Is a startup screen an evil? If so, isn't it a necessary evil?

[lindakladivova]

@HuidaeCho You are right, Huidae. I'm thinking about different variants, but somehow I can't think of the possibility that the startup screen would be completely removed. It is probably a necessary evil :-)
You suggest to create a new mapset in the last used location, but add an input textbox. But there is another situation, the last used location can be deleted, what to do then?
We can use the concept of the last used location, and thus reduce the number of cases when the startup screen appears, but we probably won't get rid of the startup screen completely.

My point is that even though I remember myself when I started with GRASS at school, seeing just the startup screen first without any notion of how the software itself looks like - it was a nightmare for me. I think we agree on that. :-) In the current solution, this "nightmare" can still happen even to a completely new user (student at school) since GRASS could be used by another student earlier.

But maybe something like Moritz's proposal could be done here: https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup#ProposalB1Moritz:Openintoapredefinedlat-longlocationbutgiveinformationmessage . We could boot into the demolocation (into the PERMANENT mapset or user mapset, depending on what is available, as we need a mapset to boot into), but show the user a startup screen in front of the software, which will be similar to the one we already have - allowing users to open or create a new environment. But at the same time, if he does not know what to do, he will be able to click and start in demolocation. @HuidaeCho What do you think about that?

@landam Won't you join the discussion too?

[marisn]

@HuidaeCho You are right, Huidae. I'm thinking about different variants, but somehow I can't think of the possibility that the startup screen would be completely removed. It is probably a necessary evil :-)

IMHO evil is dropping user into a random location/mapset. Locations are tightly linked to SRS and thus such approach would promote users to just work with whatever SRS got chosen by a chance. Yes, the old startup screen wasn't easy to understand for first timers. Still the new approach gives nothing for experienced users like me – first thing I do on start up is to change location/mapset thus removing any advantages of skipping startup screen.
If first time user friendliness is the target, bring in Clippy style wizard helping to make right choice.

[lindakladivova]

@marisn Yes, dropping the user into a random location/mapset is evil, but I tried to explain properly in Info Bar why it is like that. And according to the second survey, it helps. I think people want to see some data - they suppose to see a map... not startup screen where they stuck. So, I think that now we lead the first-time user well (or at least better than before).

But I agree that the use of demolocation as a workaround for every user when the last used mapset is not in a usable state is not a good solution...

BTW, by Clippy wizard, do you mean something like Info Bar for first-time user but not as a part of demolocation but the part of the old startup screen and Location Wizard? I was also thinking about some help in Location Wizard because getting through the Location Wizard is probably the most difficult step the first-time user makes. (And almost no one uses other options in LW just the first one).

[petrasovaa]

IMHO evil is dropping user into a random location/mapset. Locations are tightly linked to SRS and thus such approach would promote users to just work with whatever SRS got chosen by a chance. Yes, the old startup screen wasn't easy to understand for first timers. Still the new approach gives nothing for experienced users like me – first thing I do on start up is to change location/mapset thus removing any advantages of skipping startup screen.

I am not sure if you used master branch for past couple months, if not, I suggest to test it to see how the start up looks like now. The workflow is now that you get into last used location, and in if you want to change it, there is data catalog right in front of you and you just switch the mapset from there. Data catalog basically serves here as startup screen, but is much better. I believe the workflow is much easier for both new and old users. It brings some new questions (this issue), but I don't think it's such a big deal.

[HuidaeCho]

First, I think this is a very important question. Can we even detect if a mapset is being used by someone else? Do we have a such mechanism?

@HuidaeCho You are right, Huidae. I'm thinking about different variants, but somehow I can't think of the possibility that the startup screen would be completely removed. It is probably a necessary evil :-)
You suggest to create a new mapset in the last used location, but add an input textbox. But there is another situation, the last used location can be deleted, what to do then?

If the last used location is deleted, we should prompt the user and ask her what she wants to do instead of dropping her in a random location.

We can use the concept of the last used location, and thus reduce the number of cases when the startup screen appears, but we probably won't get rid of the startup screen completely.

I don't really think that the old startup was a major reason for user unfriendliness. Even commercial ArcGIS Pro has a startup screen. IMO, it is more of the concept of SRS-based locations/mapsets, the CLI nature of GRASS, and less appealing (non-native?) look of GUI that push back beginner users. Eliminating the startup wouldn't fix any of these issues until we change the architecture of data storage, which itself is a huge project and breaks backward compatibility.

My point is that even though I remember myself when I started with GRASS at school, seeing just the startup screen first without any notion of how the software itself looks like - it was a nightmare for me. I think we agree on that. :-) In the current solution, this "nightmare" can still happen even to a completely new user (student at school) since GRASS could be used by another student earlier.

I would say, going through the initial startup (including SRS selection) could be a "nightmare" for many novice users (not just not being able to see what it looks like), but that initial process is actually quite useful to remind them that the data structure of GRASS is different from other GIS systems. If we just put them in whatever default location we (developers) chose, it can give the very wrong hint and impression that GRASS just works no matter what projections your data is in. That's just wrong and they can easily fall into a lot of mysterious traps when they try to mix data from different projections (e.g., import data in a non-compatible projection). Isn't that more evil than guiding them through the right SRS selection from the very beginning?

[HuidaeCho]

@HuidaeCho You are right, Huidae. I'm thinking about different variants, but somehow I can't think of the possibility that the startup screen would be completely removed. It is probably a necessary evil :-)

IMHO evil is dropping user into a random location/mapset. Locations are tightly linked to SRS and thus such approach would promote users to just work with whatever SRS got chosen by a chance. Yes, the old startup screen wasn't easy to understand for first timers. Still the new approach gives nothing for experienced users like me – first thing I do on start up is to change location/mapset thus removing any advantages of skipping startup screen.
If first time user friendliness is the target, bring in Clippy style wizard helping to make right choice.

I totally agree with you.

[HuidaeCho]

IMHO evil is dropping user into a random location/mapset. Locations are tightly linked to SRS and thus such approach would promote users to just work with whatever SRS got chosen by a chance. Yes, the old startup screen wasn't easy to understand for first timers. Still the new approach gives nothing for experienced users like me – first thing I do on start up is to change location/mapset thus removing any advantages of skipping startup screen.

I am not sure if you used master branch for past couple months, if not, I suggest to test it to see how the start up looks like now. The workflow is now that you get into last used location, and in if you want to change it, there is data catalog right in front of you and you just switch the mapset from there. Data catalog basically serves here as startup screen, but is much better. I believe the workflow is much easier for both new and old users. It brings some new questions (this issue), but I don't think it's such a big deal.

I've been using the new GUI workflow. First, I was confused where I'm in because I have a long list of locations and mapsets, but overall, it works fine for me.

I just don't believe that it's possible to completely eliminate some sort of a startup or a popup over the default map display. At some point if the last used mapset or a fallback mapset is unusable, we have to ask. Doing more than that (e.g., creating another default mapset or creating a new user mapset silently) just makes things worse. I don't want GRASS to create a bunch of "default" mapsets for me, which I'll have to clean up later.

So.. again, what is the definition of a "unusable" mapset and how can we detect it? Depending on this definition, we may have different solutions.

[HuidaeCho]

Actually, isn't this issue this simple?

1. last used mapset usable => open it
2. last used mapset unusable => open the mapset creation dialog (the last used location by default)
3. last used location unusable => open the location creation dialog

Cases 2 and 3 both above the map display with a world map if we want to show something? But I don't really think that's any useful when the user is asked to create a new mapset or location.

[petrasovaa]

IMHO evil is dropping user into a random location/mapset. Locations are tightly linked to SRS and thus such approach would promote users to just work with whatever SRS got chosen by a chance. Yes, the old startup screen wasn't easy to understand for first timers. Still the new approach gives nothing for experienced users like me – first thing I do on start up is to change location/mapset thus removing any advantages of skipping startup screen.

I am not sure if you used master branch for past couple months, if not, I suggest to test it to see how the start up looks like now. The workflow is now that you get into last used location, and in if you want to change it, there is data catalog right in front of you and you just switch the mapset from there. Data catalog basically serves here as startup screen, but is much better. I believe the workflow is much easier for both new and old users. It brings some new questions (this issue), but I don't think it's such a big deal.

I've been using the new GUI workflow. First, I was confused where I'm in because I have a long list of locations and mapsets, but overall, it works fine for me.

That's understandable you would be confused, it's a significant change after all. For me one of the biggest advantages is seeing the content of the mapset if I don't remember what is the mapset I want to switch to.

I just don't believe that it's possible to completely eliminate some sort of a startup or a popup over the default map display. At some point if the last used mapset or a fallback mapset is unusable, we have to ask. Doing more than that (e.g., creating another default mapset or creating a new user mapset silently) just makes things worse. I don't want GRASS to create a bunch of "default" mapsets for me, which I'll have to clean up later.

I don't have a complete solution, but I think we could use the Infobars (on top of data catalog), that would inform you something wrong happened and offer solutions. E.g. "Your last used mapset has been deleted, you are currently in demolocation, please switch or create a new mapset" or something along those lines. It would inform, explain and suggest action.

So.. again, what is the definition of a "unusable" mapset and how can we detect it? Depending on this definition, we may have different solutions.

Mapset doesn't exist, is used already (detected by .gislock file, on Unix only), belongs to different user (file owner is someone else), or directory is not mapset. Overall I would say these don't happen very often.

[petrasovaa]

Actually, isn't this issue this simple?

1. last used mapset usable => open it
2. last used mapset unusable => open the mapset creation dialog (the last used location by default)
3. last used location unusable => open the location creation dialog

Cases 2 and 3 both above the map display with a world map if we want to show something? But I don't really think that's any useful when the user is asked to create a new mapset or location.

You might not want to create new mapset/location, maybe you want to switch. Having full data catalog there gives you all the options.

[HuidaeCho]

Last used mapset (important, not fresh) =>

1. Mapset doesn't exist, but location still exists: Only last used mapset is deleted
2. Mapset and location both don't exist, but its path is inside a GRASS location
3. Mapset and locaiton both don't exist and its path is not inside a GRASS location
4. Mapset with .gislock (UN*X only): It could be me trying to recover from a crashed GRASS session. Delete .gislock option
5. Mapset owner changed? How come it was usable before, but not now because of ownership?
6. Directory is not a mapset, but its parent is a location: It was the last used mapset, but now it's not even a mapset.
7. Directory and its parent directory are not a mapset and a location, respectively, but its grandparent directory is a GRASS database: Wow... I lost the whole location?
8. Directory, its parent, and its grandparent directories are not a mapset, a location, and a GRASS database, respectively.

Case 1: Ask the user if she wants to create a new mapset with the name of the last used mapset. It's just possible because there is no such directory at this point.

Case 2: Ask the user if she wants to create a new location and mapset with the last used names. Again, it's possible because there is no such directory and subdirectory.

Case 3: We're not inside a GRASS database anymore. 0) create a new GRASS database dialog.

Case 4a: Only in UN*X, check the owner of the last used mapset (.gislock) and if it's the same user, still ask the user if she wants to proceed because she may have another session on another machine. 1) proceed, 2) select another mapset in the same location or whatever location, 3) create a new map in the same location (suggested by default) or another (can be changed).

Case 4b: If it's a different user, drop 1) proceed from above and only 2) and 3)

Case 5: 2) and 3) above, but really, why has the ownership changed in the first place? That is a more serious problem, I would say.

Case 6: I have to worry about data loss, not about a new random mapset thing.. Anyway, if it's a broken mapset (there are still some GRASS files in there and if it's fixable... I doubt, but), 4) fix, 2) and 3) above. If it's not related to GRASS at all (but was a mapset before?), 2) and 3) because its parent directory is still a GRASS location.

Case 7: Because its parent directory is not a GRASS location anymore. 3) only

Case 8: Because its grandparent directory is not a GRASS database anymore. 0) above.

[HuidaeCho]

Actually, isn't this issue this simple?

1. last used mapset usable => open it
2. last used mapset unusable => open the mapset creation dialog (the last used location by default)
3. last used location unusable => open the location creation dialog

Cases 2 and 3 both above the map display with a world map if we want to show something? But I don't really think that's any useful when the user is asked to create a new mapset or location.

You might not want to create new mapset/location, maybe you want to switch. Having full data catalog there gives you all the options.

Yes, simply failing to start in the last used mapset and showing a warning message should be OK. Is it ever possible to start GRASS outside any mapset currently? Starting GRASS, but not selecting any mapset with an empty map display can be a simple enough solution, I think.

[wenzeslaus]

If first time user friendliness is the target, bring in Clippy style wizard helping to make right choice.

Everybody just loves Clippy, so let me introduce Grassy the Hungry Cow:

 ______________________________________
/ Hi, I'm Grassy. I'll help you digest \
\ GRASS well and not get fed up by it. /
 --------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
_\|/__\|/__\|/_ ||     ||  _\|/__\|/_

[ninsbl]

You might not want to create new mapset/location, maybe you want to switch. Having full data catalog there gives you all the options.

Fully agreed. The data catalog covers the relevant functionality now.
That said, if a .gislock file is present (which probably is a relatively common scenario), asking for a confirmation to start in the latest mapset never the less would be good..

And just like @HuidaeCho, I would prefer that no mapsets or locations are created automatically if latest mapset is not in usable state. As an example: in my institute servers are restarted every month automatically and running GRASS sessions are terminated abnormaly. That would lead to a number of created mapsets regularly....

[HuidaeCho]

You might not want to create new mapset/location, maybe you want to switch. Having full data catalog there gives you all the options.

Fully agreed. The data catalog covers the relevant functionality now.
That said, if a .gislock file is present (which probably is a relatively common scenario), asking for a confirmation to start in the latest mapset never the less would be good..

And just like @HuidaeCho, I would prefer that no mapsets or locations are created automatically if latest mapset is not in usable state. As an example: in my institute servers are restarted every month automatically and running GRASS sessions are terminated abnormaly. That would lead to a number of created mapsets regularly....

That's exactly why we don't want to create a new mapset silently. I think the simplest solution in this case would be start GRASS without selecting any mapset at all with a warning and let the user choose what to do (not from any startup, but from the current data catalog). No more startup is needed if we can start GRASS outside a mapset.

[wenzeslaus]

I would prefer that no mapsets or locations are created automatically if latest mapset is not in usable state. [...] That would lead to a number of created mapsets regularly....

Creating a new mapset every time is not necessary. If the created mapset has a recognizable name (or is recognizable in some other way), it can just use that one again. The only time a another one is created is when the existing one is already in use, e.g., when you start a third GRASS instance while having two already running.

[wenzeslaus]

No more startup is needed if we can start GRASS outside a mapset.

That's a big if. No, not impossible, there is a clear - although only theoretical - distinction between runtime environment versus the connected/open location/mapset. However, here, we are looking for a solution for 8.0.

[veroandreo]

see #1400

[lindakladivova]

Closed by #1400 .