[GRASS-dev] d.menu, d.ask

Can d.menu, d.ask, and i.ask be removed? Nothing appears to use them
(except each other; d.ask uses d.menu and i.ask).

d.menu is one of the few users of D_popup(), which I'd like to remove.

d.zoom used it, but only from yes() which isn't itself used, so I've
removed that. d.rast.edit is the only other user; if d.menu is
removed, D_popup can be moved into d.rast.edit until it is replaced.

Apart from being an artifact of using libraster as a GUI toolkit,
D_popup() is one of the few users of the R_panel_*() functions. The
only other users are non-essential functionality in d.barscale and
d.what.vect, i.ask (again), i.[v]points (which should be superseded by
the gis.m georectifier) and i.ortho.photo (which has replaced v.digit
as the primary obstacle to a decent graphics architecture).

--
Glynn Clements <glynn@gclements.plus.com>

On Sun, 2007-03-11 at 17:38 +0000, Glynn Clements wrote:

Can d.menu, d.ask, and i.ask be removed? Nothing appears to use them
(except each other; d.ask uses d.menu and i.ask).

I moved the few imagery modules that used it away from i.ask awhile ago.
I believe it only exists for legacy/add-on purposes.

Apart from being an artifact of using libraster as a GUI toolkit,
D_popup() is one of the few users of the R_panel_*() functions. The
only other users are non-essential functionality in d.barscale and
d.what.vect, i.ask (again), i.[v]points (which should be superseded by
the gis.m georectifier) and i.ortho.photo (which has replaced v.digit
as the primary obstacle to a decent graphics architecture).

IIRC, i.[v]points are hanging around because they haven't been
incorporated into i.ortho.photo. Maybe keep them in the tree, modify
the top level TODO, but remove them from the Makefile until they get
integrated? I know it already exists in the TODO, but it would be nice
to note why they no longer work.

I'm well on my way to doing this, but my implementation makes use of
BLAS/LAPACK. Maybe this won't be such an issue anymore, now that I've
managed to get BLAS/LAPACK working correctly with gcc4+. However, other
issues remain. I can tackle some of these problems if there is someone
else willing to help with the GUI coding (I don't know my way around
Tcl/Python as well as I should).

--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785

Glynn Clements wrote:

Can d.menu, d.ask, and i.ask be removed? Nothing appears to use them
(except each other; d.ask uses d.menu and i.ask).

While I agree that they* should be removed in time, they shouldn't be
removed during the 6.x line. Nothing in GRASS may use them (except each
other), but that is not to say that there isn't some user app out there
using them. While I don't need d.menu in my work, I've always found it
to be very interesting to play with.

[*] + i.[v]points + xterm based libedit stuff

Two ways out without grinding useful development to a halt-

a) Is there a way to isolate the needed code in lib_ancient or somewhere
and conditionalize that so it+modules doesn't get built if
./config --without-x?

b) We start on GRASS 7.x. IMO we should decide on if we want to use a
wxPython GUI or Tcl GUI for GRASS 6.4 before we decide to start that,
and do the raster format dir rearangement as the first task. I presume
the low-level raster format change can happen later, just use different
element names for the new format ($MAPSET/raster/$MAPNAME/element).

Apart from being an artifact of using libraster as a GUI toolkit,
D_popup() is one of the few users of the R_panel_*() functions. The
only other users are non-essential functionality in d.barscale

I'm a big fan of the 'd.barscale -m' try-before-you-buy functionality;
In fact I've always meant to port that to d.text.* and d.legend, but so
far haven't found the time. It would be slower, but some form of 100%
panel swap or overlay might work as a way to keep the functionality
while removing R_panel_() ?

and d.what.vect, i.ask (again), i.[v]points (which should be
superseded by the gis.m georectifier) and i.ortho.photo (which has
replaced v.digit as the primary obstacle to a decent graphics
architecture).

i.[v]points remains my prefered georectifying tool, and there is still
functionality that is not present in the Tcl version. Again, yes tag it
as end-of-line; but don't remove it during 6.x.

TCL d.rast.edit

I look forward to trying it out. Overlay numbers are needed; arrows
aren't critical; updated colors would be nice.

thanks,
Hamish

Hamish wrote:

> Can d.menu, d.ask, and i.ask be removed? Nothing appears to use them
> (except each other; d.ask uses d.menu and i.ask).

While I agree that they* should be removed in time, they shouldn't be
removed during the 6.x line. Nothing in GRASS may use them (except each
other), but that is not to say that there isn't some user app out there
using them. While I don't need d.menu in my work, I've always found it
to be very interesting to play with.

[*] + i.[v]points + xterm based libedit stuff

Two ways out without grinding useful development to a halt-

a) Is there a way to isolate the needed code in lib_ancient or somewhere
and conditionalize that so it+modules doesn't get built if
./config --without-x?

Either the panel stuff can be removed from the drivers, or it can't.
If it's removed, anything which tries to use it will fail.

> Apart from being an artifact of using libraster as a GUI toolkit,
> D_popup() is one of the few users of the R_panel_*() functions. The
> only other users are non-essential functionality in d.barscale

I'm a big fan of the 'd.barscale -m' try-before-you-buy functionality;
In fact I've always meant to port that to d.text.* and d.legend, but so
far haven't found the time. It would be slower, but some form of 100%
panel swap or overlay might work as a way to keep the functionality
while removing R_panel_() ?

Interaction belongs in the GUI, not in modules.

The panel stuff has fewer users than R_get_location_*, so getting to
the point where it can be removed is less work.

> and d.what.vect, i.ask (again), i.[v]points (which should be
> superseded by the gis.m georectifier) and i.ortho.photo (which has
> replaced v.digit as the primary obstacle to a decent graphics
> architecture).

i.[v]points remains my prefered georectifying tool, and there is still
functionality that is not present in the Tcl version.

In which case, the functionality needs to be added to the Tcl version.

Again, yes tag it
as end-of-line; but don't remove it during 6.x.

Is there an expected timeline for 7.x? If so, does that signify a
point at which fundamental changes to the graphics architecture can
commence?

If not, i.e. if i.ortho.photo *has* to continue to work until such
time that someone sees fit to write an alternative (if that ever
happens), then the graphics architecture will forever be limited to a
Tek4105 emulation, and I may as well give up now.

IMHO, I don't think that we can wait forever for decent graphics. The
biggest danger is that the "you can't remove that because someone
still uses it" problem will end up solving itself when no-one actually
uses GRASS any more. I'd prefer people to set achievable goals than to
insist on having everything and ending up with nothing.

> TCL d.rast.edit

I look forward to trying it out. Overlay numbers are needed;

The category number for the cell under the pointer is displayed in the
status bar, but if the category numbers *need* to be overlayed (bear
in mind that these may be several digits long, which means that you
need very large cells), I can add that.

arrows aren't critical;

It isn't whether they're critical. If they're even *useful*, I can add
them easily enough (although it would be preferable if the aspect map
was given as a command-line option, otherwise I need to add a map
browser).

updated colors would be nice.

Right now, there doesn't appear to be any simple way to determine the
colour for a specific category from outside of C.

The Tcl/Tk d.rast.edit gets the categories for the map being edited
from r.out.ascii, and the colours from r.out.ppm. Thus, it knows the
colour for each category (or FP value) which actually occurs in the
original map.

If you decide to set a cell to a category which wasn't already in use,
it has no idea what colour it should be, and (AFAICT) no simpler way
to find out than:

  $ r.mapcalc "$tempmap = $newval"
  $ r.colors $tempmap rast=$inmap
  $ r.out.ppm $tempmap out=$tempfile
  $ g.remove rast=$tempmap

  % image create photo tempimg -file $tempfile
  % set rgb [tempimg get 0 0]
  % image delete tempimg
  % file delete $tempfile

Which is incredibly inefficient (and possibly error-prone).

Right now, if it doesn't know the correct colour, it uses white. The
edited map has its colour table copied from the original map, so they
will show up correctly in the final map, just not in the editor.

--
Glynn Clements <glynn@gclements.plus.com>

Hi,

2007/3/13, Glynn Clements <glynn@gclements.plus.com>:

[snip]

Is there an expected timeline for 7.x? If so, does that signify a
point at which fundamental changes to the graphics architecture can
commence?

no exact timeline exists AFAIK. There is plan to migrate to SVN in
connection to GRASS7. I hope it will be done soon.

Martin

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

Martin Landa wrote on 03/13/2007 02:05 PM:

Hi,

2007/3/13, Glynn Clements <glynn@gclements.plus.com>:
[snip]

Is there an expected timeline for 7.x? If so, does that signify a
point at which fundamental changes to the graphics architecture can
commence?

no exact timeline exists AFAIK. There is plan to migrate to SVN in
connection to GRASS7. I hope it will be done soon.

Martin

Bernhard,
we would like to do the SVN migration rather sooner than later.
We offer to play with a full snapshot of the CVS repository here locally
(kindly receiving a copy from you) and try to migrate it here at IRST
in a local server to see how it works for branches etc.

Then we'll report back and give suggestions for the real migration
(which could be on "wald" or, if that's not possible, some OSGeo
infrastructure).
Since the bugtracker is already running on "wald" and svn also there,
it might be natural to keep the GRASS source code there, too, for the time
being.

Please let us know if you could package the CVS repository server-side into
a tarball.

Thanks,
Markus

On Tuesday 13 March 2007 15:43, Markus Neteler wrote:

Martin Landa wrote on 03/13/2007 02:05 PM:

> no exact timeline exists AFAIK. There is plan to migrate to SVN in
> connection to GRASS7. I hope it will be done soon.

we would like to do the SVN migration rather sooner than later.

Fine.
I think wald is ready for this in principle.

We offer to play with a full snapshot of the CVS repository here locally
(kindly receiving a copy from you) and try to migrate it here at IRST
in a local server to see how it works for branches etc.

Then we'll report back and give suggestions for the real migration

This would be helpful of course, we did some scripting here for the last
few migrations we did, so we do have some experience.
(Maybe Bernhard H. or Thomas have some pointers.)

Please let us know if you could package the CVS repository server-side into
a tarball.

Sure we could pack it up. All modules would be 585 MByte.
Can you send my your OpenPGP key, we could place it on an access controlled
area so you can download and send you the link.

Best,
Bernhard

--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

* Bernhard Reiter <bernhard@intevation.de> [20070313 15:59]:

> Please let us know if you could package the CVS repository server-side into
> a tarball.

Sure we could pack it up. All modules would be 585 MByte.
Can you send my your OpenPGP key, we could place it on an access controlled
area so you can download and send you the link.

The GRASS CVS repository is available via anonymous rsync since July 2002
at rsync://rsync.intevation.de/grass

Regards,
Thomas

--
thomas@intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Osnabrück - Registereintrag: Amtsgericht Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Just a couple of comments.

First, THANKS very much Glynn for working on this.

On 3/12/07 10:59 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

b) We start on GRASS 7.x. IMO we should decide on if we want to use a
wxPython GUI or Tcl GUI for GRASS 6.4 before we decide to start that,
and do the raster format dir rearangement as the first task. I presume
the low-level raster format change can happen later, just use different
element names for the new format ($MAPSET/raster/$MAPNAME/element).

This is a good point. The wxPython GUI is coming along very well, thanks to
the efforts of Jáchym and Martin. I've finally been able to rejoin the
development. With 3 (or more???) of us working on it, it should move along
at a nice pace.

Apart from being an artifact of using libraster as a GUI toolkit,
D_popup() is one of the few users of the R_panel_*() functions. The
only other users are non-essential functionality in d.barscale

I'm a big fan of the 'd.barscale -m' try-before-you-buy functionality;
In fact I've always meant to port that to d.text.* and d.legend, but so
far haven't found the time. It would be slower, but some form of 100%
panel swap or overlay might work as a way to keep the functionality
while removing R_panel_() ?

I've already implemented the TclTk equivalent of -m for d.barscale, d.text,
and d.legend in the current GUI. (At least it works for me and my students).

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

Michael Barton wrote:

The wxPython GUI is coming along very well, thanks to
the efforts of Jáchym and Martin. I've finally been able to rejoin the
development. With 3 (or more???) of us working on it, it should move along
at a nice pace.

So, how does one try this out?

--
Glynn Clements <glynn@gclements.plus.com>

Glynn,

You can down load it from the GRASS Addons svn server
<https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_
grassaddons_gui_>

Most of the files need to go into $GISBASE/etc/wx. If you want to try the
gis_set.py replacement or the wizard, you'll need to put them into
$GISBASE/etc and edit init.sh (the one on the server does not work as is,
but is partly edited to work).

From the grass command line start it up with $GISBASE/etc/wx/gism2.py (this

will probably change to just gism.py in a day or so).

I've attached a screenshot of the GIS Manager window version that I just
committed to give some idea.

Michael

On 3/13/07 2:12 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

The wxPython GUI is coming along very well, thanks to
the efforts of Jáchym and Martin. I've finally been able to rejoin the
development. With 3 (or more???) of us working on it, it should move along
at a nice pace.

So, how does one try this out?

__________________________________________
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

(attachments)

wxgrass1.jpeg

Glynn Clements wrote:

Is there an expected timeline for 7.x?

That is entirely up to the fine folks on this list; I would guess that
when the time comes, we know & we do it. Maybe then is now? I would not
object to it happening as soon as the SVN server is up and running. (no
technical reason for that, just a nice time for it to happen)

my wishes for the GRASS 7.0.0 release
* native MS windows fully stable and equal
  - worthy of a major point release, if simply for the PR value
* wxPython fully implemented for all GUIs
  - no or minimal Tcl, for a consistent user experience
    keep Tcl as non-default, optional "oldgui" ??? (answer that later)
* no more interactive d.*, xterm GUIs, etc
* centralized $MAPSET/raster/$MAPNAME/element
* more?
  - would a new raster format mean a new major point? or ok as long
    as lib fns were backwards compatible with the old format? too much
    to ask to support both? or r.convert module, like G6's v.convert?

the raster format changes could mean a time of dual branch development
like we had for Radim+Markus working on 5.1/5.7/6 and most everyone else
working on 5.0/5.4. Markus may have some stern words about that. :wink:

If so, does that signify a point at which fundamental changes to the
graphics architecture can commence?

I guess we could restate the question as do we want/need a GRASS 6.4
stable release, or should we continue in devel mode all the way to 7.0?

(FWIW, I see no current need for a stable 6.4*, but 6.3.0 would be a
nice milestone once winGrass is usable. If no 6.4 is planned, then there
is no need for a new SVN branch for 7.0 devel, we just continue with
6.3. If there is demand for a 6.4.0, we start a 6.5 branch in SVN and
cull away)

[*] r.li could be safely backported to 6.2? Tcl GUI updates less so but
we shouldn't abandon them. I guess they will be the day-to-day GUI
during wxPython devel, so post 6.2 Tcl GUI work wouldn't be for nothing.
??

The 6.x problem is not with fundamental changes to the underlying
architecture, that is wide open during a development minor version, and
AFAIAC go for it. The issue is changing the user interface to the
extent that scripts/ books/ tutorials/ training/ data for "GRASS 6" no
longer works with "GRASS 6". So we are free to "get our ducks in a row"
now, and we should do that, we just have to make an effort to minimize
user pain as we go.

When it is apparent that we have reached the point where the effort to
maintain backwards compatibility is a big time+energy sink, we trigger
the start of GRASS 7 development, without regret.

If not, i.e. if i.ortho.photo *has* to continue to work until such
time that someone sees fit to write an alternative (if that ever
happens), then the graphics architecture will forever be limited to a
Tek4105 emulation, and I may as well give up now.

I think we can, today, clearly make a list of things that will not be in
GRASS 7. Firstly a list of lib fn families, and secondly a list of
modules. Presumably replacements GUIs for missing modules will come
on-line in proportion to the demand for module's functionality.

IMHO, I don't think that we can wait forever for decent graphics. The
biggest danger is that the "you can't remove that because someone
still uses it" problem will end up solving itself when no-one actually
uses GRASS any more. I'd prefer people to set achievable goals than to
insist on having everything and ending up with nothing.

We just have to call it GRASS 7. As that is just a number it is simple to
change. No need to artificially slow down development to keep 6.x alive.
e.g. People with need for GRASS 5.4 can still use that if they want,
without loss of functionality, new devel switching to GRASS 6 hasn't
changed that. And GRASS 7 devel won't hurt those who still want to use
GRASS 6. So no worries.

Hamish

Hamish wrote:

That is entirely up to the fine folks on this list; I would guess that
when the time comes, we know & we do it. Maybe then is now? I would not
object to it happening as soon as the SVN server is up and running. (no
technical reason for that, just a nice time for it to happen)

my wishes for the GRASS 7.0.0 release
* native MS windows fully stable and equal

For the native Windows version to be fully "equal", monitors need to
be made to work. Even if we ditched all of the programs which require
a monitor (e.g. i.ortho.photo), so long as d.* commands can be used
with a monitor, the absence of monitors will make Windows less than
equal.

* no more interactive d.*, xterm GUIs, etc

By "interactive d.*", are you talking solely of the use of the mouse,
or about the ability to use them with monitors rather than within
gis.m?

In any case, saying "no more interactive d.*" for 7.0.0 stable and (in
your previous message) means that's going to be a long way off. And a
lot of the changes to the graphics architecture cannot even *start*
until the R_get_location_with_* cruft is ditched. Once that does
happen, the graphics architecture is going to become highly unstable.

IOW, a new graphics architecture remains almost as far away now as it
does when it was first discussed a few years back.

* centralized $MAPSET/raster/$MAPNAME/element
* more?
  - would a new raster format mean a new major point? or ok as long
    as lib fns were backwards compatible with the old format? too much
    to ask to support both? or r.convert module, like G6's v.convert?

Your wish list is too long. Given the glacial pace of GRASS
development, a version with all of these features won't be ready
within the next decade.

> If so, does that signify a point at which fundamental changes to the
> graphics architecture can commence?

I guess we could restate the question as do we want/need a GRASS 6.4
stable release, or should we continue in devel mode all the way to 7.0?

(FWIW, I see no current need for a stable 6.4*, but 6.3.0 would be a
nice milestone once winGrass is usable. If no 6.4 is planned, then there
is no need for a new SVN branch for 7.0 devel, we just continue with
6.3. If there is demand for a 6.4.0, we start a 6.5 branch in SVN and
cull away)

[*] r.li could be safely backported to 6.2? Tcl GUI updates less so but
we shouldn't abandon them. I guess they will be the day-to-day GUI
during wxPython devel, so post 6.2 Tcl GUI work wouldn't be for nothing.
??

The 6.x problem is not with fundamental changes to the underlying
architecture, that is wide open during a development minor version, and
AFAIAC go for it. The issue is changing the user interface to the
extent that scripts/ books/ tutorials/ training/ data for "GRASS 6" no
longer works with "GRASS 6". So we are free to "get our ducks in a row"
now, and we should do that, we just have to make an effort to minimize
user pain as we go.

You can't make *fundamental* architectural changes without some of
that "leaking" into user-visible changes.

When it is apparent that we have reached the point where the effort to
maintain backwards compatibility is a big time+energy sink, we trigger
the start of GRASS 7 development, without regret.

The effor to maintain backwards compatibility has *always* been a big
time and energy sink.

With regard to the graphics architecture, the need to support
standalone display drivers is by far the biggest obstacle. If the
raster/display libraries were simply rendering libraries (like e.g.
GD), any changes or enhancements would only require 1/10th as much
effort.

> If not, i.e. if i.ortho.photo *has* to continue to work until such
> time that someone sees fit to write an alternative (if that ever
> happens), then the graphics architecture will forever be limited to a
> Tek4105 emulation, and I may as well give up now.

I think we can, today, clearly make a list of things that will not be in
GRASS 7. Firstly a list of lib fn families, and secondly a list of
modules. Presumably replacements GUIs for missing modules will come
on-line in proportion to the demand for module's functionality.

However, the billion-dollar question is this: if a module *doesn't*
get re-implemented in a reasonable time-frame, can it be dropped, or
does it continue to block progress indefinitely?

It seems that certain modules are considered too important to drop,
but not important enough for anyone to actually re-implement them.

[Yes, I'm thinking primarily about i.ortho.photo; the other stuff I
could do myself if necessary.]

> IMHO, I don't think that we can wait forever for decent graphics. The
> biggest danger is that the "you can't remove that because someone
> still uses it" problem will end up solving itself when no-one actually
> uses GRASS any more. I'd prefer people to set achievable goals than to
> insist on having everything and ending up with nothing.

We just have to call it GRASS 7. As that is just a number it is simple to
change. No need to artificially slow down development to keep 6.x alive.
e.g. People with need for GRASS 5.4 can still use that if they want,
without loss of functionality, new devel switching to GRASS 6 hasn't
changed that.

Hmm. Anyone using 5.4 can't share vector data with anyone using 6.x.
Also, any bug fixes to 6.x won't get back-ported to 5.4.

The same will be true once work starts on 7.x.

And GRASS 7 devel won't hurt those who still want to use
GRASS 6. So no worries.

That's fine so long as there aren't any major problems with 6.x. Once
you start making changes which affect a lot of code, back-porting
fixes ceases to become viable.

--
Glynn Clements <glynn@gclements.plus.com>

Michael Barton wrote:

You can down load it from the GRASS Addons svn server
<https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_
grassaddons_gui_>

I already got the code with:

  svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons/gui

But I just got a bunch of files with no clue what to do with them.

Most of the files need to go into $GISBASE/etc/wx. If you want to try the
gis_set.py replacement or the wizard, you'll need to put them into
$GISBASE/etc and edit init.sh (the one on the server does not work as is,
but is partly edited to work).

Making it more straightforward to use should be a priority.

If necessary, move it out of SVN and into the main CVS repository.

From the grass command line start it up with $GISBASE/etc/wx/gism2.py (this
will probably change to just gism.py in a day or so).

  $ $GISBASE/etc/wx/gism2.py
  bash: /opt/grass-6.3.cvs/etc/wx/gism2.py: Permission denied
  $ chmod +x $GISBASE/etc/wx/gism2.py
  $ $GISBASE/etc/wx/gism2.py
  Traceback (most recent call last):
    File "/opt/grass-6.3.cvs/etc/wx/gism2.py", line 5, in ?
      import wx.lib.customtreectrl as CT
  ImportError: No module named customtreectrl

Presumably I need a specific version of wxWidgets or wxPython?

--
Glynn Clements <glynn@gclements.plus.com>

[merging in Glynn's answer at bottom]

On Wed, Mar 14, 2007 at 08:02:18PM +1300, Hamish wrote:

Glynn Clements wrote:
> Is there an expected timeline for 7.x?

That is entirely up to the fine folks on this list; I would guess that
when the time comes, we know & we do it. Maybe then is now? I would not
object to it happening as soon as the SVN server is up and running. (no
technical reason for that, just a nice time for it to happen)

We can seriously think about it once the migration to SVN is
done.

my wishes for the GRASS 7.0.0 release
* native MS windows fully stable and equal
  - worthy of a major point release, if simply for the PR value

I hope to see major MS-Windows support already in 6.3.0!
At least we were telling so for some months... and not too
much seems to be missing.

* wxPython fully implemented for all GUIs
  - no or minimal Tcl, for a consistent user experience
    keep Tcl as non-default, optional "oldgui" ??? (answer that later)
* no more interactive d.*, xterm GUIs, etc
* centralized $MAPSET/raster/$MAPNAME/element
* more?
  - would a new raster format mean a new major point? or ok as long
    as lib fns were backwards compatible with the old format? too much
    to ask to support both? or r.convert module, like G6's v.convert?

New raster format definitely deserved a major version number.

the raster format changes could mean a time of dual branch development
like we had for Radim+Markus working on 5.1/5.7/6 and most everyone else
working on 5.0/5.4. Markus may have some stern words about that. :wink:

A period of dual branch development won't be avoidable. Maybe
SVN is helpful in this regard.

> If so, does that signify a point at which fundamental changes to the
> graphics architecture can commence?

I guess we could restate the question as do we want/need a GRASS 6.4
stable release, or should we continue in devel mode all the way to 7.0?

I don't see a reason why not having a 6.4 stable release.

(FWIW, I see no current need for a stable 6.4*, but 6.3.0 would be a
nice milestone once winGrass is usable.

Right. Basically the winGRASS port completion (say, that relevant
modules and startup are working) is holding 6.3.0 now.

If no 6.4 is planned, then there
is no need for a new SVN branch for 7.0 devel, we just continue with
6.3. If there is demand for a 6.4.0, we start a 6.5 branch in SVN and
cull away)

In order to maintain the history, we have to move the entire CVS to
SVN first. Means, that 6.3.0 could come from SVN if the winGRASS port
completion takes more months (hopefully not).

[*] r.li could be safely backported to 6.2?

I highly recommend to do testing of r.li.* first. I have fixed a
few tons of issues and added some test script to
raster/r.li/TODO
based on spearfish. I get all sort of suspect results (see there)!

Tcl GUI updates less so but
we shouldn't abandon them. I guess they will be the day-to-day GUI
during wxPython devel, so post 6.2 Tcl GUI work wouldn't be for nothing.
??

at least 'd.m' seems to be unmaintained and probably almost unused.

The 6.x problem is not with fundamental changes to the underlying
architecture, that is wide open during a development minor version, and
AFAIAC go for it. The issue is changing the user interface to the
extent that scripts/ books/ tutorials/ training/ data for "GRASS 6" no
longer works with "GRASS 6". So we are free to "get our ducks in a row"
now, and we should do that, we just have to make an effort to minimize
user pain as we go.

When it is apparent that we have reached the point where the effort to
maintain backwards compatibility is a big time+energy sink, we trigger
the start of GRASS 7 development, without regret.

> If not, i.e. if i.ortho.photo *has* to continue to work until such
> time that someone sees fit to write an alternative (if that ever
> happens), then the graphics architecture will forever be limited to a
> Tek4105 emulation, and I may as well give up now.

I think that it is our policy to not discontinue modules in a release
cycle. So i.ortho.photo should remain in 6.x.
Brad has proposed a series of improvements to i.ortho.photo and AFAIK
already implemented most of them. Why don't we take a look at these?

I think we can, today, clearly make a list of things that will not be in
GRASS 7. Firstly a list of lib fn families, and secondly a list of
modules. Presumably replacements GUIs for missing modules will come
on-line in proportion to the demand for module's functionality.

This list should go into the Wiki, here it's quickly getting lost.

> IMHO, I don't think that we can wait forever for decent graphics. The
> biggest danger is that the "you can't remove that because someone
> still uses it" problem will end up solving itself when no-one actually
> uses GRASS any more. I'd prefer people to set achievable goals than to
> insist on having everything and ending up with nothing.

We just have to call it GRASS 7.

Agreed. Just start it. But call it GRASS 7. Following gravity law,
folks will migrate over (as it did for the 5.x -> 5.7 -> 6.0 path).

As that is just a number it is simple to
change. No need to artificially slow down development to keep 6.x alive.
e.g. People with need for GRASS 5.4 can still use that if they want,
without loss of functionality, new devel switching to GRASS 6 hasn't
changed that. And GRASS 7 devel won't hurt those who still want to use
GRASS 6. So no worries.

Other example: We are updating our book to GRASS 6.3. So it would only
partially work with GRASS 7 once it is there. But that will take time.
There will be necessarily overlap between 6.x and 7.x development.

#######

On Wed, Mar 14, 2007 at 12:40:33PM +0000, Glynn Clements wrote:

However, the billion-dollar question is this: if a module *doesn't*
get re-implemented in a reasonable time-frame, can it be dropped, or
does it continue to block progress indefinitely?

It may block progress in the current release but not in a higher
version number. So, i.ortho.photo should not be dropped from 6.x
but could be for 7.x.

It seems that certain modules are considered too important to drop,
but not important enough for anyone to actually re-implement them.

concerning i.ortho.photo:
- besides "important" there can be also a knowledge gap, i.e. that
  nobody of the *current* team is *able* to implement it again
- Brad proposed a series of improvements:
  http://grass.itc.it/pipermail/grass-dev/2006-December/028073.html
  I suggest to revisit this.

Markus

On Wed, Mar 14, 2007 at 12:48:18PM +0000, Glynn Clements wrote:

Michael Barton wrote:

> You can down load it from the GRASS Addons svn server
> <https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_
> grassaddons_gui_>

I already got the code with:

  svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons/gui

But I just got a bunch of files with no clue what to do with them.

Michael, Jachym,

please add a Makefile there to simplify installation.
Also a README explaining the minimum requirements and,
if possible, hints where to get things like CustomTreeCtrl
and how to get it into a standard python installation.

thanks
Markus

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14/03/07 14:19, Markus Neteler wrote:

[merging in Glynn's answer at bottom]

On Wed, Mar 14, 2007 at 08:02:18PM +1300, Hamish wrote:

Glynn Clements wrote:

Is there an expected timeline for 7.x?

That is entirely up to the fine folks on this list; I would guess that
when the time comes, we know & we do it. Maybe then is now? I would not
object to it happening as soon as the SVN server is up and running. (no
technical reason for that, just a nice time for it to happen)

We can seriously think about it once the migration to SVN is
done.

my wishes for the GRASS 7.0.0 release
* native MS windows fully stable and equal
  - worthy of a major point release, if simply for the PR value

I hope to see major MS-Windows support already in 6.3.0!
At least we were telling so for some months... and not too
much seems to be missing.

Well, at this stage Paul and I (whenever work and kids leave me some
time) seem to be the only ones actually working on this. If this is such
a priority, then more people need to become involved, at least for testing.

I have only started a more systematic test drive and have already come
up with a whole series of issues (of which some might not be winGRASS
related). And this is only using some very basic import/export and
display modules...

Maybe we should make daily/weekly binary snapshots available so that
every person on this list that has access to a windows machine can try
to reproduce the last three tasks they did in GNU/Linux, Cygwin or Mac
OSX with the native version ?

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF9/+MMiPFf/8qzFYRAtgKAJ9v33qZMWpcPSH7jlzXGg5bch+aegCeMyPc
ogZIk22KyaZ+hW3lEf3owYA=
=ykoY
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14/03/07 13:40, Glynn Clements wrote:

Hamish wrote:

That is entirely up to the fine folks on this list; I would guess that
when the time comes, we know & we do it. Maybe then is now? I would not
object to it happening as soon as the SVN server is up and running. (no
technical reason for that, just a nice time for it to happen)

my wishes for the GRASS 7.0.0 release
* native MS windows fully stable and equal

For the native Windows version to be fully "equal", monitors need to
be made to work. Even if we ditched all of the programs which require
a monitor (e.g. i.ortho.photo), so long as d.* commands can be used
with a monitor, the absence of monitors will make Windows less than
equal.

I would plead for accepting less than equal and not spend much time
trying to make monitors work.

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+APqMiPFf/8qzFYRAoYqAJ9mfXYyGddIXE4adHrADY9QmBR9uQCeJAhc
uurWdFT4O7TKoQmLSHgp40Y=
=Ugvn
-----END PGP SIGNATURE-----

On 3/14/07 5:48 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

$ $GISBASE/etc/wx/gism2.py
bash: /opt/grass-6.3.cvs/etc/wx/gism2.py: Permission denied
$ chmod +x $GISBASE/etc/wx/gism2.py
$ $GISBASE/etc/wx/gism2.py
Traceback (most recent call last):
File "/opt/grass-6.3.cvs/etc/wx/gism2.py", line 5, in ?
   import wx.lib.customtreectrl as CT
ImportError: No module named customtreectrl

Presumably I need a specific version of wxWidgets or wxPython?

Glynn,

Because the Python/wxPython versions will tend to become defacto 'frozen' as
soon as many people start to use this, we're trying to do initial
development with the most current stable versions of both.

This is currently Python 2.5 and wxPython 2.8.1.1

OTOH, customtreectrl is available as a separate download somewhere (Andrea
Gavena is the author I think), released in early 2006. Similarly, the
notebook control that we're using (FlatNotebook) was released in October
2006. Both are now included in the main wxPython distribution and provide
nice functionality over the older tree and notebook controls that is
especially useful in the GRASS context.

With respect to installation, I think that Jáchym or Martin is planning to
produce a regular Python package as soon as we have something that works.
About 6 months ago, the GUI actually displayed maps in the Python canvas (to
show that it would indeed work). Since that time, the code has undergone
significant restructuring and refactoring. In the process, the ability to
actually display something has been broken AFAICT. But we're getting close
to putting the pieces back together and have some real functionality again.

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

This sounds very reasonable in overall approach.

Michael

On 3/14/07 12:02 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Glynn Clements wrote:

Is there an expected timeline for 7.x?

That is entirely up to the fine folks on this list; I would guess that
when the time comes, we know & we do it. Maybe then is now? I would not
object to it happening as soon as the SVN server is up and running. (no
technical reason for that, just a nice time for it to happen)

my wishes for the GRASS 7.0.0 release
* native MS windows fully stable and equal
  - worthy of a major point release, if simply for the PR value
* wxPython fully implemented for all GUIs
  - no or minimal Tcl, for a consistent user experience
    keep Tcl as non-default, optional "oldgui" ??? (answer that later)
* no more interactive d.*, xterm GUIs, etc
* centralized $MAPSET/raster/$MAPNAME/element
* more?
  - would a new raster format mean a new major point? or ok as long
    as lib fns were backwards compatible with the old format? too much
    to ask to support both? or r.convert module, like G6's v.convert?

the raster format changes could mean a time of dual branch development
like we had for Radim+Markus working on 5.1/5.7/6 and most everyone else
working on 5.0/5.4. Markus may have some stern words about that. :wink:

If so, does that signify a point at which fundamental changes to the
graphics architecture can commence?

I guess we could restate the question as do we want/need a GRASS 6.4
stable release, or should we continue in devel mode all the way to 7.0?

(FWIW, I see no current need for a stable 6.4*, but 6.3.0 would be a
nice milestone once winGrass is usable. If no 6.4 is planned, then there
is no need for a new SVN branch for 7.0 devel, we just continue with
6.3. If there is demand for a 6.4.0, we start a 6.5 branch in SVN and
cull away)

[*] r.li could be safely backported to 6.2? Tcl GUI updates less so but
we shouldn't abandon them. I guess they will be the day-to-day GUI
during wxPython devel, so post 6.2 Tcl GUI work wouldn't be for nothing.
??

The 6.x problem is not with fundamental changes to the underlying
architecture, that is wide open during a development minor version, and
AFAIAC go for it. The issue is changing the user interface to the
extent that scripts/ books/ tutorials/ training/ data for "GRASS 6" no
longer works with "GRASS 6". So we are free to "get our ducks in a row"
now, and we should do that, we just have to make an effort to minimize
user pain as we go.

When it is apparent that we have reached the point where the effort to
maintain backwards compatibility is a big time+energy sink, we trigger
the start of GRASS 7 development, without regret.

If not, i.e. if i.ortho.photo *has* to continue to work until such
time that someone sees fit to write an alternative (if that ever
happens), then the graphics architecture will forever be limited to a
Tek4105 emulation, and I may as well give up now.

I think we can, today, clearly make a list of things that will not be in
GRASS 7. Firstly a list of lib fn families, and secondly a list of
modules. Presumably replacements GUIs for missing modules will come
on-line in proportion to the demand for module's functionality.

IMHO, I don't think that we can wait forever for decent graphics. The
biggest danger is that the "you can't remove that because someone
still uses it" problem will end up solving itself when no-one actually
uses GRASS any more. I'd prefer people to set achievable goals than to
insist on having everything and ending up with nothing.

We just have to call it GRASS 7. As that is just a number it is simple to
change. No need to artificially slow down development to keep 6.x alive.
e.g. People with need for GRASS 5.4 can still use that if they want,
without loss of functionality, new devel switching to GRASS 6 hasn't
changed that. And GRASS 7 devel won't hurt those who still want to use
GRASS 6. So no worries.

Hamish

__________________________________________
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