a change a while back changed things so that after you complete setting up
a new location, and after it asks you if you want to set the default
bounds, it automatically launches in the PERMANENT mapset.
Day to day use of PERMANENT as your working mapset is not good practice
and the auto-launch behaviour should be reverted. Instead it should act
like the text location creation tool and ask you if you want to create a
new mapset, auto-filling in the $user name as a suggestion for what to
call it.
If "create mapset" name is left blank, it should quietly return to the
location/mapset as if you'd pressed cancel, instead of giving a python
error. From there you can work with just PERMANENT if you are really dead-
set on doing that. If an invalid name is given it should give an error
message about that and either return you to the create new mapset prompt
or the main startup window.
Then back on the startup window it should present you with that mapset
highlighted and leave you to press "start grass". e.g., what if you have
a new system and want to set up 10 new locations? I do appreciate the
spirit of helpfulness and assisting with the workflow, but it shouldn't go
so far as executing decisions on the users' behalf.
Perhaps this came in with the code to automatically import the
georeferenced map you created a new location from? (and that one should
ask you first, e.g. the geofile may be massive and you don't want to
import it)
thanks,
Hamish
ps- the location wizard, on the whole, continues to be really awesome and
a brilliant first impression for new users
Hamish, You were faster today. I would also suggest to go back to previous
behaviour when user was taken back to start page. It's possible to
preselect new location and PERMANENT mapset to save clicks, but it is also
giving ability to create more mapsets and work in one of them.
When I create new location, I usually want to import data first. So
launching in PERMANENT seems to be reasonable from this point of view.
Replying to [ticket:1889 hamish]:
> Perhaps this came in with the code to automatically import the
georeferenced map you created a new location from? (and that one should
ask you first, e.g. the geofile may be massive and you don't want to
import it)
> When I create new location, I usually want to import data first.
perhaps, but that's not a decision that should be made for someone else.
Guiding people to use PERMANENT as their working mapset by default is not
good, and that far outweighs any one-off convenience + is dysfunctional in
a multi-user/team setting.
> > e.g. the geofile may be massive and you don't want to import it
> It asks.
Replying to [comment:4 annakrat]:
> Any other opinions on this?
I am 100% with Hamish: automatically entering a mapset without having the
user explicitely ask for it is a very bad idea IMHO. Is one click really
too much to ask of a user ?
Please try r55185. It asks for new mapset after creating location and goes
back to startup window.
I noticed that startup window gui accepts non-ascii mapset and location
name but later, the gui complains about it. See #1293. I suggest to check
the input and do not allow diacritic.
Replying to [comment:7 annakrat]:
> Please try r55185. It asks for new mapset after creating location and
goes back to startup window.
This looks good to me, now. We might want to think about a tooltip that
explains why creating a mapset (other than PERMANENT) is a good idea, but
that's cosmetics.
> I noticed that startup window gui accepts non-ascii mapset and location
name but later, the gui complains about it. See #1293. I suggest to check
the input and do not allow diacritic.
>
+1
Is there a possibility to call a Python equivalent of G_legal_name() ?
In r55231 I added some doc for r55229 but actually, I don't understand the
issue completely. I know about ticked #1293 and I can see that functions
G_legal_filename or G_check_input_output_name (file legal_name.c) are used
only on a few places (according to grep and programming manual). There is
some check in G_parser function because it is not possible to create map
with dot or slash but probably G_legal_filename is not used. (There is a
warning which is reported twice but that is another issue.)
I've tried to create map with non-latin characters but I'm not able to do
it. wxGUI fails with some bugs and command line (Bash Shell) does not
accept my characters and it does some other things instead such as
cleaning the line.
> In r55231 I added some doc for r55229 but actually, I don't understand
the issue completely. I know about ticked #1293 and I can see that
functions G_legal_filename or G_check_input_output_name (file
legal_name.c) are used only on a few places (according to grep and
programming manual). There is some check in G_parser function because it
is not possible to create map with dot or slash but probably
G_legal_filename is not used. (There is a warning which is reported twice
but that is another issue.)
G_parser() doesn't check for legal file names. However, G_open() etc do,
and those functions are used by Rast_open_new() etc.
> I've tried to create map with non-latin characters but I'm not able to
do it.
Bytes above 126 aren't allowed in filenames. That excludes the DEL
character as well as all non-ASCII characters, regardless of the encoding.
Replying to [comment:8 mlennert]:
> This looks good to me, now. We might want to think about a tooltip that
explains why creating a mapset (other than PERMANENT) is a good idea, but
that's cosmetics.
> > I noticed that startup window gui accepts non-ascii mapset and
location name but later, the gui complains about it. See #1293. I suggest
to check the input and do not allow diacritic.
> >
> +1
Done in r55278 using legal_name function. It applies for creating new
location/mapset and changing their names. Please test (this is a blocker).
Replying to [ticket:1889 hamish]:
> Hi,
>
> a change a while back changed things so that after you complete setting
up a new location, and after it asks you if you want to set the default
bounds, it automatically launches in the PERMANENT mapset.
it doesn't anymore now.
>
> Day to day use of PERMANENT as your working mapset is not good practice
and the auto-launch behaviour should be reverted. Instead it should act
like the text location creation tool and ask you if you want to create a
new mapset, auto-filling in the $user name as a suggestion for what to
call it.
it does now.
>
>
> Perhaps this came in with the code to automatically import the
georeferenced map you created a new location from? (and that one should
ask you first, e.g. the geofile may be massive and you don't want to
import it)
>
just tested with a fresh build of relbr64. After setting the region bounds
it is still printing some g.region debug output to the terminal.
when the create new mapset gui pops up, it would be good to have a few
sentence tooltip available explaining what MAPSET means, and a [Help]
button at the bottom that opened up $GISBASE/docs/html/helptext.html.
> closing the ticket?
not before it has been ported to all branches. (please don't do
development work in the release branch and then not sync with the dev
branches. The release branch must be treated with great care, only code
tested in the relevant dev branch should be backported to the release
branch- by backporting it to the release branch you're personally signing
off that the code is tested and works. tx)
Replying to [comment:14 hamish]:
> Hi,
>
> just tested with a fresh build of relbr64. After setting the region
bounds it is still printing some g.region debug output to the terminal.
> when the create new mapset gui pops up, it would be good to have a few
sentence tooltip available explaining what MAPSET means, and a [Help]
button at the bottom that opened up $GISBASE/docs/html/helptext.html.
Help button added in r55297. Please could you add the help text (I
wouldn't use tooltip, just add another sentence to the message)?
>
> > closing the ticket?
>
> not before it has been ported to all branches. (please don't do
development work in the release branch and then not sync with the dev
branches. The release branch must be treated with great care, only code
tested in the relevant dev branch should be backported to the release
branch- by backporting it to the release branch you're personally signing
off that the code is tested and works. tx)
Replying to [comment:14 hamish]:
> not before it has been ported to all branches. (please don't do
development work in the release branch and then not sync with the dev
branches. The release branch must be treated with great care, only code
tested in the relevant dev branch should be backported to the release
branch- by backporting it to the release branch you're personally signing
off that the code is tested and works. tx)
just small note: it's probably related to the fact, that you are probably
only developer who wants to do "development" in GRASS 6 branches. There
were several discussions in the past, and I don't want to open this topic
again. The result will the same. Please bear in mind, that you are
probably only one from devs who really wants to keep `develbranch_6`
alive. Development should be done only in trunk! Anyway this is one of
consequences, all of us need to maintain three branches just because we
didn't decided that we don't need `develbranch_6`. This is meant to open
discussion again, it's just a reminder.
> not before it has been ported to all branches. (please don't do
development work in the release branch and then not sync with the dev
branches. The release branch must be treated with great care, only code
tested in the relevant dev branch should be backported to the release
branch- by backporting it to the release branch you're personally signing
off that the code is tested and works. tx)
>
Also, I did the changes first in release branch because now it's not time
to test it elsewhere, then backport and test it again.
Btw, this 'blocker' could have been opened a long time ago and not just
before release.
Replying to [comment:17 annakrat]:
> Also, I did the changes first in release branch because now it's not
time to test it elsewhere, then backport and test it again.
>
> Btw, this 'blocker' could have been opened a long time ago and not just
before release.
good point, more over there were open four blockers in one day by one
person just when we claimed to release RC3 and then final. We should
really change policy in this sense. Ideally should come two RC in shorter
period (two or three weeks) and then final. Currently we have RC1 in
October, RC2 in December. RC3 who knows. Sometimes I have impression that
there are people who don't care about releases (which is acceptable) and
people who are in the result blocking (or making releasing process
painful). One release if usually story for half of the year or more (see
number of RC and time). It would be nice to have more releases (two per
year) with smaller resistance. Just my 2 cents. Not related to this
ticket. My personal opinion which shouldn't be reported here.
There is nothing wrong with reporting issues. The point is that we must
decide what is the blocker and what is only a feature request. Moreover,
some issues, blockers or non-blockers, are just only for some other
release, not for the current. The decision which type, priority and
release is associated with each ticket can be made by anyone, not only the
original reporter.