[GRASS-dev] GRASS 7 timeline

[Hamish]

Michael Barton wrote:
> 
> This is actually pretty good news from one viewpoint. All the commands
> below now have all or most of their interactive functionality
> replicated in TckTk except for
> 
> bin/d.path

easy to write a replacement with v.net.path

> bin/r.digit (a pretty primitive module anyway; v.digit+v.to.rast is
>   better)

IMHO GUI canvas + r.in.poly is simple enough to be better. But yes
v.digit + v.to.rast will provide the functionality.

AFAIK there is no functionality replacement for d.extract, d.geodesic
(draw great circle lines), and d.nviz (which awaits a rewrite anyway).


Nothing so great on the list of unportables that can't be overcome.

My suggestion would be (in order)
 1. do the move to SVN
 2. release 6.3.0 (post-alpha winGRASS)
 3. start GRASS 6.5 without d.{primarily-interactive} modules or
    anything not intended for 7.0.  [or call it 6.7? shrug.]

then let the GUI replacements trickle into the 6.5 branch as they are
written. by the time GRASS 7.0 is released we should aim for no
(perceived) functionality loss.

* but zero functionality loss is probably unneeded. e.g from GRASS 5 we
don't have v.in.gshhs or the v.digit tie-ins with digitizing tablets. I
don't think anyone has minded much that "obsolete" functionality has
gone away.


I'm not sure if we would want to make HEAD follow the 6.3 or 6.5 branch
+ "make mix" for the other; or 100% new devel in 6.5, and let 6.3 die at
whatever pace people want to stop backporting things to it, but leading
to a 6.4 release in a more tangible time frame than a 7.0 release.

The point being that having to double-commit every change to a non-
display module would be a royal pain in the foot and a recipe for
breakage.


Brad:
> But you're right that i.class will be easier, so I'll start working on
> that tonight to make sure I know my way around the new GUI scheme.

All this double coding (tcl, wxPy) seems wasteful. I guess getting the
interacive separated from the gui is a good idea and makes the second
time around that much easier, and the Tcl replacements seem to be
functional after only a few days, so I won't protest too much.

Brad:  [re. i.ortho.photo]
> Then there is the small issue of do we want 8 modules or 1 module to
> complete a single task (ie. a front-end)?  Can we put it to a vote and
> be done with it?

Glynn:
> There isn't any GUI "scheme" for self-contained applications, beyond
> the general principle that any identifiable process which isn't
> inherently interactive should be accessible from the command line.
..
> Use Tcl/Tk (or wxPython if you prefer) for interactively editing data,
> and stick to normal command-line-driven C modules for processing the
> data.

I'm confused about the question. A single GUI linking to many apps? A
single monolithic app? UNIX style little programs which do one job well?
Are you talking about imagery/i.ortho.photo/menu/menu.c ?

A nice GUI front end to well defined sub-apps seems to work ok so far..?
Are there reusable parts useful to other i.* modules?
Is it useful for the i.photo submodules share common lib fns?
Will breaking it up require global vars?

I don't like a holding a vote when most of us are ignorant of the problem.


Hamish