[GRASS-dev] GRASS 7 timeline

[Glynn Clements]

Hamish 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.

v.digit doesn't have a tool to draw circles.

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

d.geodesic doesn't require a mouse; you can use coor= instead. This
would be easy enough to integrate into gis.m.

More generally, it would be useful to be able to mark points on a map
canvas, then pass the coordiantes to arguments to commands (both those
used in display layers and those run from the menus).

> 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?

> 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 ?

He's talking about i.orpho.photo, and whether we want one module with
a mode= option or a separate module for each task.

As a programmer, I prefer modularity, which means that I favour
several smaller modules over one large module. You don't have to worry
about whether function F reads or modifies variable V if the two are
in different programs.

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