[GRASS-dev] Re: [GRASS-user] [GRASSLIST:1181] d.m/d.gis mysteries..

Maciej_Sieczka2 · October 30, 2006, 12:54pm

Dear Moritz,

Moritz Lennert wrote:

a discussion whether there is a way to satisfy Maciej's desires

Can I kindly ask you to reconsider this, and having done that, rephrase
it in a way which does not ridicule me? Because, as I understand what
you are suggesting, you mean that I'm expecting or demanding something
just to satisfy my egoistic needs, for no practical benefit to other
GRASS users. While actually I'm pointing out an important defect in
gis.m, which concerns any GRASS user.

Why I think it is an important issue: gis.m allows for changing the
current GRASS region to match the current display and to make the
display match the current region settings. Since these 2 operations are
implemented, they should work correctly, as you would expect it. Since
they don't work correctly - it is a bug.

And I completely agree with your point that if this really itches him
that much,

Again, it is not about me not liking something, whatever you mean to
make people think about it by your unfair comments.

than maybe he should think about learning tcltk and finding a
solution. Or maybe learn C and see how d.zoom does it to see if this can
be applied to gis.m...

If I had time I would have done this. What did you think?

I haven't criticized Michael or you as a person. Actually I haven't
said a single "personal" word. I criticized a defect in the software.
And I don't appreciate that you are trying to reduce the discussion to
the level of my person, insulting me with innuendos.

I absolutely think that gis.m is ready for production. And I agree that
we should discontinue d.m after 6.2.

... if the bug in gis.m is fixed.

We could maybe somewhere in the doc include a hint that if one wants
really precise region settings than this has to be done with g.region
and not with zooming.

... keeping in mind this is not a fix.

We can't deny a bug, only because nobody (yes, including me) is able to
fix it.

Kind Regards,
Maciek

mlennert · October 30, 2006, 1:31pm

Maciej,

In no way was what I wrote intended as a personal attack. If this is how
it came across, I sincerely apologize.

Up to now you are the only one who has raised this issue as a problem.
Maybe this is because you are the only one conscious of it and many people
are actually misusing gis.m thinking that they get a precision which they
are actually not getting. Maybe it is because those who need such level of
precision have the habit of going through g.region. Or maybe it is because
those who need it are working on the command line and so don't use gis.m.
I don't know the reasons...

So, the first question to be asked is: does everyone agree that this is a
bug ? If yes, then I agree completely that this needs to be fixed. But as
always developer time is limited...and there are other bugs in GRASS which
those who have the skills find more important.

The current situation definitely is not easy as we are in a transition
phase between gui's with a very important step being gis.m, but at the
same time this is already poised to be replaced. This makes the issue more
difficult, as Michael has to deal with three different GUIs at the same
time, and it is not always clear which of these should be the priority.

I am willing to help you try to identify whether there are possible
solutions to the issue in gis.m, but definitely not before next week and
as Markus wants to release 6.2 tomorrow, I am afraid it will have to wait
for a bug fix release.

Moritz

On Mon, October 30, 2006 13:54, Maciej Sieczka wrote:

Dear Moritz,

Moritz Lennert wrote:

a discussion whether there is a way to satisfy Maciej's desires

Can I kindly ask you to reconsider this, and having done that, rephrase
it in a way which does not ridicule me? Because, as I understand what
you are suggesting, you mean that I'm expecting or demanding something
just to satisfy my egoistic needs, for no practical benefit to other
GRASS users. While actually I'm pointing out an important defect in
gis.m, which concerns any GRASS user.

Why I think it is an important issue: gis.m allows for changing the
current GRASS region to match the current display and to make the
display match the current region settings. Since these 2 operations are
implemented, they should work correctly, as you would expect it. Since
they don't work correctly - it is a bug.

And I completely agree with your point that if this really itches him
that much,

Again, it is not about me not liking something, whatever you mean to
make people think about it by your unfair comments.

than maybe he should think about learning tcltk and finding a
solution. Or maybe learn C and see how d.zoom does it to see if this can
be applied to gis.m...

If I had time I would have done this. What did you think?

I haven't criticized Michael or you as a person. Actually I haven't
said a single "personal" word. I criticized a defect in the software.
And I don't appreciate that you are trying to reduce the discussion to
the level of my person, insulting me with innuendos.

I absolutely think that gis.m is ready for production. And I agree that
we should discontinue d.m after 6.2.

... if the bug in gis.m is fixed.

We could maybe somewhere in the doc include a hint that if one wants
really precise region settings than this has to be done with g.region
and not with zooming.

... keeping in mind this is not a fix.

We can't deny a bug, only because nobody (yes, including me) is able to
fix it.

Kind Regards,
Maciek

Maciej_Sieczka2 · October 30, 2006, 2:34pm

Moritz Lennert wrote:

Maciej,

In no way was what I wrote intended as a personal attack. If this is how
it came across, I sincerely apologize.

OK, no problem.

Up to now you are the only one who has raised this issue as a problem.
Maybe this is because you are the only one conscious of it and many people
are actually misusing gis.m thinking that they get a precision which they
are actually not getting. Maybe it is because those who need such level of
precision have the habit of going through g.region. Or maybe it is because
those who need it are working on the command line and so don't use gis.m.
I don't know the reasons...

Who raises a given issue is not a criterion. The only criterion is
wheter the issue is there or not. Since I have started using GRASS I
have found many bugs, including numerous long-standing, which nobody
has raised before. Also other folks have found bugs which I was never
aware of.

So, the first question to be asked is: does everyone agree that this is a
bug ?

We don't need to vote on this. There is a functionality which doesn't
do what it designed for, and this results in corrupted region settings.
This is a bug. I'm not going to debate on whether 1=1 anymore.

If yes, then I agree completely that this needs to be fixed. But as
always developer time is limited...and there are other bugs in GRASS which
those who have the skills find more important.

The current situation definitely is not easy as we are in a transition
phase between gui's with a very important step being gis.m, but at the
same time this is already poised to be replaced. This makes the issue more
difficult, as Michael has to deal with three different GUIs at the same
time, and it is not always clear which of these should be the priority.

I am willing to help you try to identify whether there are possible
solutions to the issue in gis.m,

Thanks for the offer, but you can only help someone able to fix the bug.

but definitely not before next week and
as Markus wants to release 6.2 tomorrow, I am afraid it will have to wait
for a bug fix release.

I didn't even try to say that the 6.2 release should be hold off till
the bug is fixed, because I know this is not realistic. There are many
bugs not fixed and this doens't make me trying to hold of the release
either. Since I remember, GRASS has been always released with known
bugs not fixed, and GRASS developers convinced me that it is inevitable
- too little people working on the project compared to size of the
codebase. Since I can't fix any bug myself I don't even dare to tell
others what to do anymore. But this doesn't mean I should not inform
others about bugs I found, wishing that soemone can fix it. I'm not
going to pretend there is no bug.

There have been many bugs squashed in gis.m recently by Michael.
Encouraged by that, until this another bug has cropped out, I've been
thinking gis.m will really become stable soon and d.m can dropped
altogether. Now that this bug is known and there is no cure for it,
until the bug is fixed, d.m should remain at least as an alternative.
I, personally, would even prefer d.m as the default GUI back, due to
this particular bug - the high risk of corrupted region settings is too
serious for me to bear it. But I'm not going to insist or argue on
that, I'll settle for what others decide for. At least don't remove d.m
until the bug is fixed.

Maciek

cmbarton · October 30, 2006, 3:04pm

Moritz,

This is a very good idea.

The whole interface should be better documented, and I am periodically
plagued by pangs of guilt along this line. There is a page out there, but
things have changed so fast that I haven't kept up with it. It should
probably a mini-manual of its own.

For example, I've never gotten around to documenting either the new profiler
or georectifier (guilt, guilt, guilt!). Now this is catching up with me as
people start to use it and run into some confusion, so that it is not clear
if there is a bug or if it is simply not explained well enough. I keep
hoping that someone else will do this. But it is a bit of a chicken and egg,
I fear. The entire system needs to be explained enough for someone to use it
and explain it to others.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Mon, 30 Oct 2006 11:07:36 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Maciej Sieczka <tutey@o2.pl>, Hamish <hamish_nospam@yahoo.com>,
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] d.m/d.gis mysteries..

We could maybe somewhere in the doc include a hint that if one wants
really precise region settings than this has to be done with g.region
and not with zooming.

mlennert · October 30, 2006, 3:43pm

Michael Barton wrote:

Moritz,

This is a very good idea.

The whole interface should be better documented, and I am periodically
plagued by pangs of guilt along this line. There is a page out there, but
things have changed so fast that I haven't kept up with it. It should
probably a mini-manual of its own.

For example, I've never gotten around to documenting either the new profiler
or georectifier (guilt, guilt, guilt!). Now this is catching up with me as
people start to use it and run into some confusion, so that it is not clear
if there is a bug or if it is simply not explained well enough. I keep
hoping that someone else will do this. But it is a bit of a chicken and egg,
I fear. The entire system needs to be explained enough for someone to use it
and explain it to others.

I have found that for explaining the GUI, small movies such as Sören's[1] often work wonders. Maybe we could integrate a few short ones into the official GRASS doc. Might be quicker than trying to write something where you describe the GUI...

Moritz

[1] http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/grass63feature_tour.html

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Mon, 30 Oct 2006 11:07:36 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Maciej Sieczka <tutey@o2.pl>, Hamish <hamish_nospam@yahoo.com>,
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] d.m/d.gis mysteries..

We could maybe somewhere in the doc include a hint that if one wants
really precise region settings than this has to be done with g.region
and not with zooming.

cmbarton · October 30, 2006, 9:29pm

Even better idea. Who has the software to do this?

Michale
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Mon, 30 Oct 2006 16:43:22 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] d.m/d.gis mysteries..

Michael Barton wrote:

Moritz,

This is a very good idea.

The whole interface should be better documented, and I am periodically
plagued by pangs of guilt along this line. There is a page out there, but
things have changed so fast that I haven't kept up with it. It should
probably a mini-manual of its own.

For example, I've never gotten around to documenting either the new profiler
or georectifier (guilt, guilt, guilt!). Now this is catching up with me as
people start to use it and run into some confusion, so that it is not clear
if there is a bug or if it is simply not explained well enough. I keep
hoping that someone else will do this. But it is a bit of a chicken and egg,
I fear. The entire system needs to be explained enough for someone to use it
and explain it to others.

I have found that for explaining the GUI, small movies such as
Sören's[1] often work wonders. Maybe we could integrate a few short ones
into the official GRASS doc. Might be quicker than trying to write
something where you describe the GUI...

Moritz

[1]
http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/grass63fea
ture_tour.html

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Mon, 30 Oct 2006 11:07:36 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Maciej Sieczka <tutey@o2.pl>, Hamish <hamish_nospam@yahoo.com>,
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] d.m/d.gis mysteries..

We could maybe somewhere in the doc include a hint that if one wants
really precise region settings than this has to be done with g.region
and not with zooming.

Dylan_Beaudette1 · October 30, 2006, 9:33pm

After following this thread for a while, I would like to throw in a couple
thoughts.

On Monday 30 October 2006 06:34, Maciej Sieczka wrote:

Moritz Lennert wrote:
> Maciej,
>
> In no way was what I wrote intended as a personal attack. If this is how
> it came across, I sincerely apologize.

OK, no problem.

> Up to now you are the only one who has raised this issue as a problem.
> Maybe this is because you are the only one conscious of it and many
> people are actually misusing gis.m thinking that they get a precision
> which they are actually not getting. Maybe it is because those who need
> such level of precision have the habit of going through g.region. Or
> maybe it is because those who need it are working on the command line and
> so don't use gis.m. I don't know the reasons...

Moritz : Although I have not contributed to this discussion until now, this
bug is something that bothers me as well. In fact, the implications of the
behavior of d.zoom were not fully clear to me until Maciej pointed them out
on the list one day. Since most of my work deals with point and raster data,
strict adherence to the region settings are of the utmost importance. I now
always check, and sometimes reset, the region with the -a flag to maintain
meaningful (for me) settings.

Michael: I understand how difficult it can be to implement something that you
need, especially when you are not a programmer by trade. I am in the same
boat, and have found myself getting into trouble now and then when I dabble
into developing my own tools. You have done a tremendous effort on the gis.m
interface and should be proud. However, Maciej is correct in pointing out
that there is a bug, and that it needs to be addressed sooner than later.
Nothing puts people off more than inconsistent, or even worse, inaccurate
behavior of some product. Not to say that gis.m isn't ready for general use,
rather this issue really should be tackled with the help of the core
development team.

Who raises a given issue is not a criterion. The only criterion is
wheter the issue is there or not. Since I have started using GRASS I
have found many bugs, including numerous long-standing, which nobody
has raised before. Also other folks have found bugs which I was never
aware of.
> So, the first question to be asked is: does everyone agree that this is a
> bug ?

We don't need to vote on this. There is a functionality which doesn't
do what it designed for, and this results in corrupted region settings.
This is a bug. I'm not going to debate on whether 1=1 anymore.

> If yes, then I agree completely that this needs to be fixed. But as
> always developer time is limited...and there are other bugs in GRASS
> which those who have the skills find more important.
>
> The current situation definitely is not easy as we are in a transition
> phase between gui's with a very important step being gis.m, but at the
> same time this is already poised to be replaced. This makes the issue
> more difficult, as Michael has to deal with three different GUIs at the
> same time, and it is not always clear which of these should be the
> priority.
>
> I am willing to help you try to identify whether there are possible
> solutions to the issue in gis.m,

Thanks for the offer, but you can only help someone able to fix the bug.

> but definitely not before next week and
> as Markus wants to release 6.2 tomorrow, I am afraid it will have to wait
> for a bug fix release.

I didn't even try to say that the 6.2 release should be hold off till
the bug is fixed, because I know this is not realistic. There are many
bugs not fixed and this doens't make me trying to hold of the release
either. Since I remember, GRASS has been always released with known
bugs not fixed, and GRASS developers convinced me that it is inevitable
- too little people working on the project compared to size of the
codebase. Since I can't fix any bug myself I don't even dare to tell
others what to do anymore. But this doesn't mean I should not inform
others about bugs I found, wishing that soemone can fix it. I'm not
going to pretend there is no bug.

There have been many bugs squashed in gis.m recently by Michael.
Encouraged by that, until this another bug has cropped out, I've been
thinking gis.m will really become stable soon and d.m can dropped
altogether. Now that this bug is known and there is no cure for it,
until the bug is fixed, d.m should remain at least as an alternative.
I, personally, would even prefer d.m as the default GUI back, due to
this particular bug - the high risk of corrupted region settings is too
serious for me to bear it. But I'm not going to insist or argue on
that, I'll settle for what others decide for. At least don't remove d.m
until the bug is fixed.

Maciek

I agree with Maciej on these points, and strongly feel that d.m should remain
in the 6.x releases. Although I mainly use the d.* commands directly, I
prefer the simplicity of d.m, and would like to have it as an alternative to
the gis.m for the time being.

Cheers,

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

Joel_Pitt · October 31, 2006, 12:16am

On 10/31/06, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:

Moritz : Although I have not contributed to this discussion until now, this
bug is something that bothers me as well. In fact, the implications of the
behavior of d.zoom were not fully clear to me until Maciej pointed them out
on the list one day. Since most of my work deals with point and raster data,
strict adherence to the region settings are of the utmost importance. I now
always check, and sometimes reset, the region with the -a flag to maintain
meaningful (for me) settings.

I don't use gis.m, mainly because all my scripts interact with x
monitors. d.m is better suited as it is designed to work with the x
monitors - eventually I'll update my scripts though.

I know that if I used gis.m, and it responded in the way described in
this thread, I would be strongly discouraged from continueing using
it.

Michael: I understand how difficult it can be to implement something that you
need, especially when you are not a programmer by trade. I am in the same
boat, and have found myself getting into trouble now and then when I dabble
into developing my own tools. You have done a tremendous effort on the gis.m
interface and should be proud. However, Maciej is correct in pointing out
that there is a bug, and that it needs to be addressed sooner than later.
Nothing puts people off more than inconsistent, or even worse, inaccurate
behavior of some product. Not to say that gis.m isn't ready for general use,
rather this issue really should be tackled with the help of the core
development team.

I don't have time myself to investigate the bug, and it'd take me a
while to understand it since I don't know TCL. However, from what I
understand it it seems like you could present the user with the true
extent values from the zoom, but when drawing the PNG you could round
up the extents when zooming, and maybe add the region resolution to
each extent. Changing the region is a pretty quick process so doesn't
matter if there are multiple calls per zoom.

I guess the problem with this would be parts of vector objects that
are not in the true region showing up in png. i.e. a large vector
point icon might show up due to the icon size overlapping into the
true region.

Just some ideas - possibly you've already thought of this and I'm
missing something important...

cheers

P.S I don't mean to be purile, but surely "gis.m" isn't the best name
for the display manager when the g could be pronounced with a j sound.
Maybe [gd].mgr, [gd].gis, or [gd].grass?

--
-Joel

"Wish not to seem, but to be, the best."
-- Aeschylus

H_B · October 31, 2006, 12:26am

Moritz:

> I have found that for explaining the GUI, small movies such as
> Sören's[1] often work wonders. Maybe we could integrate a few short
> ones into the official GRASS doc. Might be quicker than trying to
> write something where you describe the GUI...

..

> [1]

http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/grass63feature_tour.html

Michael:

Even better idea. Who has the software to do this?

wiki page has been set up, with instructions (taken from the mailing list):
http://grass.gdf-hannover.de/wiki/GRASS_Education_(Free_GIS_education)#Training_Videos

Hamish

H_B · October 31, 2006, 2:13am

Maciej Sieczka wrote:

I, personally, would even prefer d.m as the default GUI back,

with a mind to making long term users happy, and making the wxpython
development easier, I'd like to extend the GRASS_GUI variable.

currently it is both a startup shell variable and a GRASS gisenv
variable. (if it exists, the former sets the latter at startup)

currently you can do

GRASS_GUI=text grass63
or
grass63 -text

to start with the command line one

GRASS_GUI=tcltk grass63
or
grass63 -gui
or
grass63 -tcltk

to start with the Tcl/Tk startup + gis.m

with this patch you can also do

grass63 -oldgui # for d.m

or

GRASS_GUI=d.m grass63

or

GRASS_GUI=gis.m grass63

or even

# rename it to whatever the wxpython GUI will be called
GRASS_GUI=wxpython grass63

when wx becomes the default just switch "grass63 -gui" to that target.

grass remembers the last one you used and uses that as the default.

WRT, d.zoom & gis.m zooming- the x monitors and d.zoom have had more
than a decade of heavy use to become mature. gis.m has had barely 9
months of developer testing to become mature. And even then, most of the
long-time developers who hold the bulk of the "institutional knowledge"
only work from the command line.... it is really great that it has come
so far so fast.

the zooming stuff is tricky business- even after all this time d.zoom
still has some problems and is far from elegant. accurate rendering &
point placement is the bread and butter of a GIS though, so it'd be nice
to have everyone happy with gis.m in the long term. Folks will be
picking points off the screen and writing down coordinates for their
field sites. All the time spent now perfecting the design choices will
pay off well, I am sure. Even if only for when we do the wxPython
version we can pick the best choices the first time.

choices are good,
Hamish

(attachments)

gui_init_options.diff (2.88 KB)

Soeren_Gebbert1 · October 31, 2006, 10:39pm

Hi,
sorry for the late response.

Markus Neteler schrieb:

(Soeren, please take a look)

On Sun, Oct 29, 2006 at 07:29:48PM +1300, Hamish wrote:

now's a great time for folks to proof-read the draft release
announcement:
http://grass.itc.it/announces/announce_grass620.html

and blurb:
http://grass.itc.it/announces/abstract_grass620.txt

Hi,

re the QA section of the announcement:
(probably a section we should strive to keep functional!)

* I just fixed a broken link to the test suite, as Summary.html no
longer exists. Changed it to the 6.2 test suite summary, which seems

Well, i have removed some md5 validation tests, because i have currently no time to generate and validate correct md5 checksums.

more relevant (and less red!). ps- on 6.2 page "Fail Summary" is empty,
maybe a "--end of fail summary--" line so it is clear entire page isn't
the fail summary?

Done.
Thanks for the feedback.

Soeren, could you re-run the test suite on 6.2.0?

Done.

* rather than link to a dull mailing list page with an incidental link
mid-page for the SOCCER site, should we link to their page directly?
http://web.soccerlab.polymtl.ca/grass-evolution/grass-browsers/grass-index-en.html

Sorry for the dull page. But right, I have updated the link to
the suggestion in the announcement.

* any point adding a link to these guys?
http://cia.navi.cx/stats/project/GRASS

Also added.

Hamish

ps- v.buffer data error listed in 6.3 test suite is probably because of
the fixed polygon cleaning bug- the result is indeed binary different,
but hopefully more correct. I don't know about the v.patch error.

I have removed the validation tests for some vector modules.
v.out.ascii is used for validation and generating md5 checksums.
Because v.out.ascii prints also the header of a vector (format=standard), the md5
checksums differs from output to output if the creation date is set.
So i need to implement a header suppression flag to v.out.ascii to
generate "stable" md5 checksums.
But this have to wait, im very busy right now .... .

I have created a special grass6.2 test suite version:
http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/GRASS_Testsuite_6.2_validation.tar.bz2

The test log is available here:
http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_grass-6.2/

Best regards
Soeren

I suggest to get out 6.2.0 by tuesday, 31 Oct.
There is no real reason to wait longer.

Markus

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

Maciej_Sieczka2 · November 1, 2006, 6:59am

Sören Gebbert wrote:

<snip>

v.out.ascii prints also the header of a vector
(format=standard), the md5
checksums differs from output to output if the creation date is set.
So i need to implement a header suppression flag to v.out.ascii to
generate "stable" md5 checksums.

v.out.ascii | awk 'NR>10' | ...

?

But this have to wait, im very busy right now .... .

Maciek

H_B · November 2, 2006, 6:56am

Hamish wrote:

with a mind to making long term users happy, and making the wxpython
development easier, I'd like to extend the GRASS_GUI variable.

..

with this patch you can also do

grass63 -oldgui # for d.m
or
GRASS_GUI=d.m grass63
or
GRASS_GUI=gis.m grass63
or even
# rename it to whatever the wxpython GUI will be called
GRASS_GUI=wxpython grass63

when wx becomes the default just switch "grass63 -gui" to that target.

grass remembers the last one you used and uses that as the default.

now applied to 6.3-cvs. tweak as needed.
(did we ever come up with a good name for the wxpython gui?)

Hamish