[GRASS-dev] Re: include wxgrass or not in 6.3.0

GRASS GIS GRASS GIS developer
1

(I have taken liberty to replace the funky
  Re: [GRASS-dev] Re: grass-dev Digest, Vol 22, Issue 33
subject)

On Feb 9, 2008 7:40 PM, Michael Barton <michael.barton@asu.edu> wrote:

On Feb 9, 2008, at 5:58 AM, grass-dev-request@lists.osgeo.org wrote:
> From: "Martin Landa" <landa.martin@gmail.com>
> 2008/2/9, Martin Landa <landa.martin@gmail.com>:
>>> For 6.3.X, I would envision a release that includes work
>>> on the Win32 port, wxGUI/Python stuff and 3D capabilities.
>>
>> Good point. Should be wxGUI included in 6.3.0. If so, I propose to
>> apply changes in configure [1], and to copy gui/wxpython to
>> releasebranch_6_3 before 6.3.0 will be tagged. (?)
>
> correction: Should be wxGUI included in 6.3.0?
>
>> From my point of view: -0
>
> So:
> 6.3.x - no wxgui
> 6.4.x - wxgui included

I think that wxPython GUI *should* be included in 6.3.0.

What about doing it in 6.3.1? We had 4 release candidates now and
it wasn't included. I would like to see at least one RC with that included
before officially publishing it.

Markus

2

Hi,

2008/2/10, Markus Neteler <neteler@osgeo.org>:

(I have taken liberty to replace the funky
  Re: [GRASS-dev] Re: grass-dev Digest, Vol 22, Issue 33
subject)
On Feb 9, 2008 7:40 PM, Michael Barton <michael.barton@asu.edu> wrote:
> On Feb 9, 2008, at 5:58 AM, grass-dev-request@lists.osgeo.org wrote:
> > From: "Martin Landa" <landa.martin@gmail.com>
> > 2008/2/9, Martin Landa <landa.martin@gmail.com>:
> >>> For 6.3.X, I would envision a release that includes work
> >>> on the Win32 port, wxGUI/Python stuff and 3D capabilities.
> >>
> >> Good point. Should be wxGUI included in 6.3.0. If so, I propose to
> >> apply changes in configure [1], and to copy gui/wxpython to
> >> releasebranch_6_3 before 6.3.0 will be tagged. (?)
> >
> > correction: Should be wxGUI included in 6.3.0?
> >
> >> From my point of view: -0
> >
> > So:
> > 6.3.x - no wxgui
> > 6.4.x - wxgui included
>
> I think that wxPython GUI *should* be included in 6.3.0.

What about doing it in 6.3.1? We had 4 release candidates now and
it wasn't included. I would like to see at least one RC with that included
before officially publishing it.

unfortunately, it has been included, even worse the old wxPython code!! see

http://trac.osgeo.org/grass/browser/grass/tags/release_20080109_grass_6_3_0RC4/gui/wxpython

I would imagine copy of wxpython stuff in 6.3.0 (based on this
situation). Changes in configure [1] or [2] would eventually become
part of 6.3.1 (if so).

Martin

[1] http://trac.osgeo.org/grass/ticket/38
[2] http://grass.gdf-hannover.de/wiki/WxPython-based_GUI_for_GRASS#Issues

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

3

On Feb 10, 2008 2:10 PM, Martin Landa <landa.martin@gmail.com> wrote:

2008/2/10, Markus Neteler <neteler@osgeo.org>:
> On Feb 9, 2008 7:40 PM, Michael Barton <michael.barton@asu.edu> wrote:
> > I think that wxPython GUI *should* be included in 6.3.0.
>
> What about doing it in 6.3.1? We had 4 release candidates now and
> it wasn't included. I would like to see at least one RC with that included
> before officially publishing it.

unfortunately, it has been included, even worse the old wxPython code!! see

http://trac.osgeo.org/grass/browser/grass/tags/release_20080109_grass_6_3_0RC4/gui/wxpython

Strange. In my local copy it isn't present.

I also checked the released tarball (xblade14-2 = grass.osgeo.org):

[neteler@xblade14-2 source]$ tar tvfz grass-6.3.0RC4.tar.gz | grep wxgra
[neteler@xblade14-2 source]$

Nothing.

I would imagine copy of wxpython stuff in 6.3.0 (based on this
situation). Changes in configure [1] or [2] would eventually become
part of 6.3.1 (if so).

Martin

[1] http://trac.osgeo.org/grass/ticket/38
[2] http://grass.gdf-hannover.de/wiki/WxPython-based_GUI_for_GRASS#Issues

Markus

4

I'd suggest having the *good* wxPython code included, no change to configure. Without the configure change, it does no harm to the existing code and can be ignored if desired. For people who want to try it, it would be there.

Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

On Feb 10, 2008, at 6:10 AM, Martin Landa wrote:

Hi,

2008/2/10, Markus Neteler <neteler@osgeo.org>:

(I have taken liberty to replace the funky
  Re: [GRASS-dev] Re: grass-dev Digest, Vol 22, Issue 33
subject)
On Feb 9, 2008 7:40 PM, Michael Barton <michael.barton@asu.edu> wrote:

On Feb 9, 2008, at 5:58 AM, grass-dev-request@lists.osgeo.org wrote:

From: "Martin Landa" <landa.martin@gmail.com>
2008/2/9, Martin Landa <landa.martin@gmail.com>:

For 6.3.X, I would envision a release that includes work
on the Win32 port, wxGUI/Python stuff and 3D capabilities.

Good point. Should be wxGUI included in 6.3.0. If so, I propose to
apply changes in configure [1], and to copy gui/wxpython to
releasebranch_6_3 before 6.3.0 will be tagged. (?)

correction: Should be wxGUI included in 6.3.0?

From my point of view: -0

So:
6.3.x - no wxgui
6.4.x - wxgui included

I think that wxPython GUI *should* be included in 6.3.0.

What about doing it in 6.3.1? We had 4 release candidates now and
it wasn't included. I would like to see at least one RC with that included
before officially publishing it.

unfortunately, it has been included, even worse the old wxPython code!! see

wxpython in grass/tags/release_20080109_grass_6_3_0RC4/gui – GRASS GIS

I would imagine copy of wxpython stuff in 6.3.0 (based on this
situation). Changes in configure [1] or [2] would eventually become
part of 6.3.1 (if so).

Martin

[1] #38 (configure.in: wxwidgets and python checks) – GRASS GIS
[2] http://grass.gdf-hannover.de/wiki/WxPython-based_GUI_for_GRASS#Issues

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

5

Hi,

2008/2/10, Markus Neteler <neteler@osgeo.org>:

> unfortunately, it has been included, even worse the old wxPython code!! see
>
> http://trac.osgeo.org/grass/browser/grass/tags/release_20080109_grass_6_3_0RC4/gui/wxpython

Strange. In my local copy it isn't present.

I also checked the released tarball (xblade14-2 = grass.osgeo.org):

[neteler@xblade14-2 source]$ tar tvfz grass-6.3.0RC4.tar.gz | grep wxgra
[neteler@xblade14-2 source]$

Nothing.

try this

tar tvfz grass-6.3.0RC4.tar.gz | grep wxpython
drwxr-xr-x neteler/neteler 0 2008-01-09 10:10 grass-6.3.0RC4/gui/wxpython/

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

6

On Feb 10, 2008 5:59 PM, Martin Landa <landa.martin@gmail.com> wrote:

2008/2/10, Markus Neteler <neteler@osgeo.org>:
> > unfortunately, it has been included, even worse the old wxPython code!! see
> >
> > http://trac.osgeo.org/grass/browser/grass/tags/release_20080109_grass_6_3_0RC4/gui/wxpython

tar tvfz grass-6.3.0RC4.tar.gz | grep wxpython
drwxr-xr-x neteler/neteler 0 2008-01-09 10:10 grass-6.3.0RC4/gui/wxpython/

Indeed!
But why isn't it in my local copy (from which RC4 derives):

[neteler@localhost grass63_release]$ svn up gui
At revision 30061.
[neteler@localhost grass63_release]$ cd gui/
[neteler@localhost gui]$ l
total 7
-rw-r--r-- 1 neteler neteler 307 Oct 2 21:53 Makefile
drwxr-xr-x 3 neteler neteler 1024 Jan 9 10:10 xml/
drwxr-xr-x 5 neteler neteler 1024 Jan 9 10:10 tcltk/
drwxr-xr-x 3 neteler neteler 1024 Jan 9 10:10 scripts/
drwxr-xr-x 3 neteler neteler 3072 Feb 10 17:36 icons/

/me confused

Markus

7

Hi,

2008/2/10, Markus Neteler <neteler@osgeo.org>:

On Feb 10, 2008 5:59 PM, Martin Landa <landa.martin@gmail.com> wrote:
> 2008/2/10, Markus Neteler <neteler@osgeo.org>:
> > > unfortunately, it has been included, even worse the old wxPython code!! see
> > >
> > > http://trac.osgeo.org/grass/browser/grass/tags/release_20080109_grass_6_3_0RC4/gui/wxpython
>
> tar tvfz grass-6.3.0RC4.tar.gz | grep wxpython
> drwxr-xr-x neteler/neteler 0 2008-01-09 10:10 grass-6.3.0RC4/gui/wxpython/

Indeed!
But why isn't it in my local copy (from which RC4 derives):

[neteler@localhost grass63_release]$ svn up gui
At revision 30061.
[neteler@localhost grass63_release]$ cd gui/
[neteler@localhost gui]$ l
total 7
-rw-r--r-- 1 neteler neteler 307 Oct 2 21:53 Makefile
drwxr-xr-x 3 neteler neteler 1024 Jan 9 10:10 xml/
drwxr-xr-x 5 neteler neteler 1024 Jan 9 10:10 tcltk/
drwxr-xr-x 3 neteler neteler 1024 Jan 9 10:10 scripts/
drwxr-xr-x 3 neteler neteler 3072 Feb 10 17:36 icons/

strange, I downloaded grass-6.3.0RC4.tar.gz right now, there is
wxpython stuff (old one)...

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

8

Hi,

2008/2/10, Markus Neteler <neteler@osgeo.org>:

On Feb 10, 2008 5:59 PM, Martin Landa <landa.martin@gmail.com> wrote:
> 2008/2/10, Markus Neteler <neteler@osgeo.org>:
> > > unfortunately, it has been included, even worse the old wxPython code!! see
> > >
> > > http://trac.osgeo.org/grass/browser/grass/tags/release_20080109_grass_6_3_0RC4/gui/wxpython
>
> tar tvfz grass-6.3.0RC4.tar.gz | grep wxpython
> drwxr-xr-x neteler/neteler 0 2008-01-09 10:10 grass-6.3.0RC4/gui/wxpython/

Indeed!
But why isn't it in my local copy (from which RC4 derives):

[neteler@localhost grass63_release]$ svn up gui
At revision 30061.
[neteler@localhost grass63_release]$ cd gui/
[neteler@localhost gui]$ l
total 7
-rw-r--r-- 1 neteler neteler 307 Oct 2 21:53 Makefile
drwxr-xr-x 3 neteler neteler 1024 Jan 9 10:10 xml/
drwxr-xr-x 5 neteler neteler 1024 Jan 9 10:10 tcltk/
drwxr-xr-x 3 neteler neteler 1024 Jan 9 10:10 scripts/
drwxr-xr-x 3 neteler neteler 3072 Feb 10 17:36 icons/

do you mean svn branch? If so, it is OK, wxpython has been removed to
avoid confusion:-) see

http://trac.osgeo.org/grass/changeset/29737

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

9

On Feb 10, 2008 6:59 PM, Martin Landa <landa.martin@gmail.com> wrote:

2008/2/10, Markus Neteler <neteler@osgeo.org>:
> On Feb 10, 2008 5:59 PM, Martin Landa <landa.martin@gmail.com> wrote:
> > 2008/2/10, Markus Neteler <neteler@osgeo.org>:
> > > > unfortunately, it has been included, even worse the old wxPython code!! see
> > > >
> > > > http://trac.osgeo.org/grass/browser/grass/tags/release_20080109_grass_6_3_0RC4/gui/wxpython

Well, now I understand this... but obviously the published RC contains
what the release branch contains.

...

do you mean svn branch? If so, it is OK, wxpython has been removed to
avoid confusion:-) see

http://trac.osgeo.org/grass/changeset/29737

Yes, now understood.
To come back to the original question:

Copying over wxpython from SVN trunk would work without extra changes
in other places? Then it should not harm...

Markus

10

Right. I agree.
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

On Feb 10, 2008, at 11:05 AM, Markus Neteler wrote:

On Feb 10, 2008 6:59 PM, Martin Landa <landa.martin@gmail.com> wrote:

2008/2/10, Markus Neteler <neteler@osgeo.org>:

On Feb 10, 2008 5:59 PM, Martin Landa <landa.martin@gmail.com> wrote:

2008/2/10, Markus Neteler <neteler@osgeo.org>:

unfortunately, it has been included, even worse the old wxPython code!! see

wxpython in grass/tags/release_20080109_grass_6_3_0RC4/gui – GRASS GIS

Well, now I understand this... but obviously the published RC contains
what the release branch contains.

...

do you mean svn branch? If so, it is OK, wxpython has been removed to
avoid confusion:-) see

Changeset 29737 – GRASS GIS

Yes, now understood.
To come back to the original question:

Copying over wxpython from SVN trunk would work without extra changes
in other places? Then it should not harm...

Markus

11

Hi,

2008/2/10, Markus Neteler <neteler@osgeo.org>:

On Feb 10, 2008 6:59 PM, Martin Landa <landa.martin@gmail.com> wrote:
> 2008/2/10, Markus Neteler <neteler@osgeo.org>:
> > On Feb 10, 2008 5:59 PM, Martin Landa <landa.martin@gmail.com> wrote:
> > > 2008/2/10, Markus Neteler <neteler@osgeo.org>:
> > > > > unfortunately, it has been included, even worse the old wxPython code!! see
> > > > >
> > > > > http://trac.osgeo.org/grass/browser/grass/tags/release_20080109_grass_6_3_0RC4/gui/wxpython

Well, now I understand this... but obviously the published RC contains
what the release branch contains.

...
> do you mean svn branch? If so, it is OK, wxpython has been removed to
> avoid confusion:-) see
>
> http://trac.osgeo.org/grass/changeset/29737

Yes, now understood.
To come back to the original question:

Copying over wxpython from SVN trunk would work without extra changes
in other places? Then it should not harm...

yes and no, since building vdigit (changes in configure script) and
other issues [1] are not stabilized we can just copy the wxpython
directory without extra backporting issues from trunk.

[1] http://grass.gdf-hannover.de/wiki/WxPython-based_GUI_for_GRASS#Issues

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

12

> > > correction: Should be wxGUI included in 6.3.0?
> > >
> > >> From my point of view: -0
> > >
> > > So:
> > > 6.3.x - no wxgui
> > > 6.4.x - wxgui included
> >
> > I think that wxPython GUI *should* be included in 6.3.0.

Markus:

> What about doing it in 6.3.1? We had 4 release candidates now and
> it wasn't included. I would like to see at least one RC with that
> included before officially publishing it.

I agree.

Martin:

unfortunately, it has been included, even worse the old wxPython
code!! see

http://trac.osgeo.org/grass/browser/grass/tags/release_20080109_grass_6_3_0RC4/gui/wxpython

It's not in the release branch, apparently removed in r29737:

http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_3/gui
(no idea how to get deleted file history (Attic) in Trac source code
browser or ViewCVS + SVN, or pull out the log message for that rev)

Martin:

I would imagine copy of wxpython stuff in 6.3.0 (based on this
situation). Changes in configure [1] or [2] would eventually become
part of 6.3.1 (if so).

...

[1] http://trac.osgeo.org/grass/ticket/38
[2]
http://grass.gdf-hannover.de/wiki/WxPython-based_GUI_for_GRASS#Issues

(trac ticket #38 is still an open issue)

We could do a quick 6.3.1 (6.3.0 with backported wx) once the above is
solved? Or wait for wx and go straight to 6.3.1?

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

13

Markus:

> Copying over wxpython from SVN trunk would work without extra
> changes in other places? Then it should not harm...

Michael:

Right. I agree.

Including it is fine with me then.

Hamish

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

14

Hi,

2008/2/10, Hamish <hamish_b@yahoo.com>:
[snip]

Markus:
> > What about doing it in 6.3.1? We had 4 release candidates now and
> > it wasn't included. I would like to see at least one RC with that
> > included before officially publishing it.

I agree.

Martin:
> unfortunately, it has been included, even worse the old wxPython
> code!! see
>
http://trac.osgeo.org/grass/browser/grass/tags/release_20080109_grass_6_3_0RC4/gui/wxpython

It's not in the release branch, apparently removed in r29737:

http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_3/gui
(no idea how to get deleted file history (Attic) in Trac source code
browser or ViewCVS + SVN, or pull out the log message for that rev)

Martin:
> I would imagine copy of wxpython stuff in 6.3.0 (based on this
> situation). Changes in configure [1] or [2] would eventually become
> part of 6.3.1 (if so).
...
> [1] http://trac.osgeo.org/grass/ticket/38
> [2]
> http://grass.gdf-hannover.de/wiki/WxPython-based_GUI_for_GRASS#Issues

(trac ticket #38 is still an open issue)

We could do a quick 6.3.1 (6.3.0 with backported wx) once the above is
solved? Or wait for wx and go straight to 6.3.1?

Apparently removing old wxpython stuff from releasebranch6_3 before
releasing 6.3.0 was mistake. This code has been included in all RC's.
I am afraid there is no good solution.

* to re-add old wxPython stuff for continuity (RC's, release) - bad
* wait for 6.3.1 (do not include wxPython in 6.3.0) - users cannot test it out
* include the current wxPython code in 6.3.0

It seems to me that the relatively good solution is to copy the
current wxPython code to releasebranch_6_3 now and not to wait for
6.3.1. Anyway it should have been done before first RC, my fault.

Regards, Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

15

On Feb 10, 2008 9:09 PM, Martin Landa <landa.martin@gmail.com> wrote:

2008/2/10, Hamish <hamish_b@yahoo.com>:

...

Apparently removing old wxpython stuff from releasebranch6_3 before
releasing 6.3.0 was mistake. This code has been included in all RC's.
I am afraid there is no good solution.

* to re-add old wxPython stuff for continuity (RC's, release) - bad
* wait for 6.3.1 (do not include wxPython in 6.3.0) - users cannot test it out

... maybe not.

* include the current wxPython code in 6.3.0

... and simply do RC5.

It seems to me that the relatively good solution is to copy the
current wxPython code to releasebranch_6_3 now and not to wait for
6.3.1.

At this point I suggest to add now and do 6.3.0RC2 with a short term
life time to get out 6.3.0.

Luckily the GRASS 6.4 branching and GRASS 7 isn't really affected here.

Markus

16

Martin:

http://grass.gdf-hannover.de/wiki/WxPython-based_GUI_for_GRASS#Issues

to quote that here:
-----
Issues
   1. rename $GISBASE/etc/wx to $GISBASE/etc/wxpython
   2. rename switch 'wx' to 'wxpython', e.g. grass63 -wxpython, g.gui
type=wxpython
   3. rename 'wxgrass' script to 'wxgui' (this scripts just runs
wxgui.py module)
   4. write g.gui module (draft)
   5. copy wxgui script to $GISBASE/etc/wxpython (not to
$GISBASE/scripts)
-----

> (trac ticket #38 is still an open issue)

[--python ./configure changes needed for vdigit]

In light of those, specifically the exposed-to-the-user renaming tasks
(2,3), it seems clear to me that wx is not ready to be released yet.
It's not far off -at all-, but those architectural issues need be dealt
with, and (quickly) tested, first. I see no reason why all 5 of those
couldn't be handled in a week.

Apparently removing old wxpython stuff from releasebranch6_3 before
releasing 6.3.0 was mistake.

why? It seems to me it was ok- the problem was mentioned on the mailing
list, discussed, a course of action agreed upon and implemented.

This code has been included in all RC's.

and it was not what we wanted to release, so it was removed. That's
what the RCs are for.

I am afraid there is no good solution.

* to re-add old wxPython stuff for continuity (RC's, release) - bad

no point,

* wait for 6.3.1 (do not include wxPython in 6.3.0) - users cannot
test it out

They can't test, but it's not ready yet, even in trunk.

* include the current wxPython code in 6.3.0

But it's not ready yet, even in trunk.

It seems to me that the relatively good solution is to copy the
current wxPython code to releasebranch_6_3 now and not to wait for
6.3.1.

But it's not ready yet, even in trunk.

Anyway it should have been done before first RC, my fault.

But it wasn't ready then in addons-svn, and it still isn't.

sorry for repeating myself, I'm not trying to be rude, just making a
point.

As I see it, we can release 6.3.0 now [11 Feb], finish above issues in
a week, copy gui/wxpython from trunk to releasebranch_6_3 then, release
that as 6.3.1RC1, then a week later release 6.3.1. [~ 1 March]
We could note in the 6.3.0 release annoucement that 6.3.1 with wx is
right around the corner.

Or we could finish above issues in a week, copy gui/wxpython from trunk
to releasebranch_6_3 then, release that as 6.3.0RC5, then a week later
release 6.3.0. [~1 March]

I think trac #38 will take longer to get right and well tested across
all platforms so should not be a blocker due to timeframe reasons. We
just accept that that's a work in progress.

Hamish

      ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

17

On Feb 10, 2008, at 4:31 PM, Hamish wrote:

Martin:

http://grass.gdf-hannover.de/wiki/WxPython-based_GUI_for_GRASS#Issues

to quote that here:
-----
Issues
   1. rename $GISBASE/etc/wx to $GISBASE/etc/wxpython
   2. rename switch 'wx' to 'wxpython', e.g. grass63 -wxpython, g.gui
type=wxpython
   3. rename 'wxgrass' script to 'wxgui' (this scripts just runs
wxgui.py module)
   4. write g.gui module (draft)
   5. copy wxgui script to $GISBASE/etc/wxpython (not to
$GISBASE/scripts)
-----

(trac ticket #38 is still an open issue)

[--python ./configure changes needed for vdigit]

In light of those, specifically the exposed-to-the-user renaming tasks
(2,3), it seems clear to me that wx is not ready to be released yet.
It's not far off -at all-, but those architectural issues need be dealt
with, and (quickly) tested, first. I see no reason why all 5 of those
couldn't be handled in a week.

I (and a few students here) are using the wxPython GUI as is right now, without worrying about issues 1-5. I agree that these should be fixed. I guess I don't see them as a hold up to including it in 6.3.0. If all are agin' it, so be it. But I'd like to see it more widely tested, and 6.3.0 will be more widely distributed and used than 6.3.1. We don't have to make a big announcement about it. I'd just like to see it available for those who want to give it a try.

FWIW, isues 1-3, and 5 can be dealt with in an hour or 2 with the SVN. The g.gui module should wait until later and isn't necessary. In fact, it probably shouldn't be released now because it will be a major change to starting up the current TclTk GUI.

My 2 cents.

Michael

18

Michael Barton wrote:

I (and a few students here) are using the wxPython GUI as is right
now, without worrying about issues 1-5. I agree that these should be
fixed. I guess I don't see them as a hold up to including it in
6.3.0.

I am not worried *at all* about the actual coding quality, just that
big parts of it (from the users' perspective) still seem be in flux.
(ie the name, how to start it, how to build it)

Will we see dozens of "why doesn't vdigit compile?" questions unless
trac #38 is done?

But I'd like to see it more widely tested,

...

I'd just like to see it available for those who want to give it a

try.

Sure, I think that two of the three primary goals for 6.3.x will be
widespread beta testing of the wxGUI and the native MS-windows build.
The third goal would be to get all the new features since 6.2.0 out to
the hungry masses for testing.

FWIW, isues 1-3, and 5 can be dealt with in an hour or 2 with the
SVN.

Right.

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

19

On Sun, 10 Feb 2008, Hamish wrote:

[...]

Sure, I think that two of the three primary goals for 6.3.x will be
widespread beta testing of the wxGUI and the native MS-windows build.
The third goal would be to get all the new features since 6.2.0 out to
the hungry masses for testing.

Yes, and don't all the new features include many usability improvements and feature enhancements to the Tcl/TK GUI parts since the last stable release? I would worry that with all the talk about wxgui these are going to be a bit overlooked and people won't realise gis.m and gis_set.tcl are much improved since 6.2. E.g. things I've been involved in and know about - font selection and improved GUI location creation. I'm sure there are lots more - Michael has been pretty responsive in fixing and tidying up little issues as they come along.

For this reason alone, not including wxgui in the release is IMHO an excellent way to make the point that gis.m is still the preferred stable GUI.

Paul

20

Hi,

2008/2/11, Hamish <hamish_b@yahoo.com>:

Martin:
> http://grass.gdf-hannover.de/wiki/WxPython-based_GUI_for_GRASS#Issues

to quote that here:
-----
Issues
   1. rename $GISBASE/etc/wx to $GISBASE/etc/wxpython

done, http://trac.osgeo.org/grass/changeset/30075,
http://trac.osgeo.org/grass/changeset/30076

   2. rename switch 'wx' to 'wxpython', e.g. grass63 -wxpython, g.gui
type=wxpython

done, http://trac.osgeo.org/grass/changeset/30077

   3. rename 'wxgrass' script to 'wxgui' (this scripts just runs
wxgui.py module)

done, http://trac.osgeo.org/grass/changeset/30078,
http://trac.osgeo.org/grass/changeset/30079

   4. write g.gui module (draft)
   5. copy wxgui script to $GISBASE/etc/wxpython (not to
$GISBASE/scripts)

can be done easily I guess

> > (trac ticket #38 is still an open issue)
[--python ./configure changes needed for vdigit]

yes, it is still open, out of 6.3.0 scope

In light of those, specifically the exposed-to-the-user renaming tasks
(2,3), it seems clear to me that wx is not ready to be released yet.
It's not far off -at all-, but those architectural issues need be dealt

we need a few days for testing now.

with, and (quickly) tested, first. I see no reason why all 5 of those
couldn't be handled in a week.

I agree.

[snip]

As I see it, we can release 6.3.0 now [11 Feb], finish above issues in
a week, copy gui/wxpython from trunk to releasebranch_6_3 then, release
that as 6.3.1RC1, then a week later release 6.3.1. [~ 1 March]
We could note in the 6.3.0 release annoucement that 6.3.1 with wx is
right around the corner.

Or we could finish above issues in a week, copy gui/wxpython from trunk
to releasebranch_6_3 then, release that as 6.3.0RC5, then a week later
release 6.3.0. [~1 March]

I would vote for RC5 approach.

I think trac #38 will take longer to get right and well tested across
all platforms so should not be a blocker due to timeframe reasons. We
just accept that that's a work in progress.

yes, I think RC5 can be released during this weekend, maybe with g.gui included.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *