Opened 10 years ago

Closed 7 years ago

Last modified 6 years ago

#1068 closed defect (wontfix)

unnecessary error information at GRASS startup

Reported by: msieczka Owned by: grass-dev@…
Priority: minor Milestone: 6.4.0
Component: Startup Version: svn-releasebranch64
Keywords: Cc:
CPU: All Platform: All

Description

Don't issue an error when a location or mapset is no longer available at startup, like:

Starting GRASS ...
BŁĄD:MAPSET ula nie został znaleziony
ERROR: Location <newLocation> not found
ERROR: Mapset <ula> not found

This is scarry.

Change History (6)

comment:1 in reply to:  description Changed 10 years ago by martinl

Priority: normalminor

Replying to msieczka:

Don't issue an error when a location or mapset is no longer available at startup, like:

Why? It's kind of error...

> Starting GRASS ...
> BŁĄD:MAPSET ula nie został znaleziony
> ERROR: Location <newLocation> not found
> ERROR: Mapset <ula> not found

This is scarry.

Really? ;-)

Well, this "message" doesn't seems to me to be a "defect"...

comment:2 Changed 10 years ago by msieczka

Component: wxGUIdefault

Why? It's kind of error...

I don't think so.

  1. Remove or rename a location using the button at wxGUI startup.
  1. Quit.
  1. Start GRASS back - and it goes:
Starting GRASS ...
BŁĄD:MAPSET ula nie został znaleziony
ERROR: Location <newLocation> not found
ERROR: Mapset <ula> not found

or e.g.:

access: No such file or directory
ERROR: LOCATION << /home/grassdata/newLocation2 >> not available

It is not an error for the location or mapset to be no longer available under the last path GRASS remembered. IMO startup procedure should handle this normally. If it can't - OK, too bad. Though I still would say this is weird.

This is scarry.

Really? ;-)

No, actually it's "scary" :).

Seriously, I really mean the user might be at least surprised with GRASS telling him it is an error that the location/mapset does not longer exist, while he removed/changed it's name using a regular GRASS tool.

comment:3 Changed 7 years ago by hamish

Component: DefaultStartup

If the last-known mapset or location isn't found any more, an error saying it isn't found seems entirely appropriate. The expected behaviour (load up the last mapset) is not possible, and any time that the expected thing isn't going to happen there should be warning bells sounding.

The thing to worry about, I think, is how well it recovers from that situation..

the current 6.x wxGUI gives this in the terminal if the mapset went away:

...
ERROR: MAPSET user1 not found
ERROR: Mapset <user1> not found

but loads up the loc'n with the list of existing mapsets.

If the loc'n is no longer there the wxGUI startup gives you:

Cleaning up temporary files ...
Starting GRASS ...
access: No such file or directory
ERROR: LOCATION << /path/to/old/name >> not available

then loads up the GISDBASE dir and selects the first loc'n there.

The -text version gives this after esc-enter, then asks if you want to create it.

Mapset <<user1>> is not available

For an invalid loc'n it is similar: asks if you wish to create a new loc'n by that name.

it all seems ok to me.

Hamish

comment:4 Changed 7 years ago by hamish

Resolution: wontfix
Status: newclosed

comment:5 Changed 7 years ago by wenzeslaus

Leaving as wontfix but note that there are some people that really think that a user should not be scarred by application's messages:

Messages should be:

  • ...
  • Informative and constructive. Tell the user the reason for a problem and help on how to solve the problem.
  • Polite, non-terrifying and non-blaming. Avoid wording that terrifies the user ("fatal", "illegal"), blames him for his behavior, and be polite.

Cited from HIG for KDE.

comment:6 Changed 6 years ago by wenzeslaus

I'm not sure how much this is related however, for GRASS 7 GUI I've committed (r57549). It changes dialogs with messages

"No GRASS location found in '%s'."
"Path '%s' doesn't exist."

to a message in the main window. It is behaves better when starting GRASS for the first time and with deleted location.

I'm not sure how to correctly implemented but I like how it behaves to the user.

Note: See TracTickets for help on using tickets.