[GRASS-dev] GRASS 7 timeline

[Glynn Clements]

Brad Douglas wrote:

> > AIUI, Brad was planning on doing this to i.class first, as it needs
> > essentially the same treatment, and i.class is a signficantly simpler
> > program than i.ortho.photo. The i.class changes haven't happened yet,
> > so having the i.ortho.photo re-write completed is still a way off.
> 
> I don't recall this, but that doesn't mean I didn't say it (I have poor
> short-term memory).  I haven't touched i.class in this regard.
> 
> Part if the reason I haven't proceeded in this direction with
> i.ortho.photo is because the API was seemingly in flux and there is
> little documentation for it that I am aware of...not that I've gone out
> of my way to look.  However, now I have v.digit to use as a reference

No you don't. v.digit is a hybrid Tcl/Tk+C application, which is a
poor choice in general. IOW, v.digit should not be used as a
reference. If you want a reference, look at gis.m's georectifier.

The reason that v.digit uses that approach is because that's
essentially how I found it, and the design of the vector library made
it hard to implement as anything other than a monolithic application. 
At least now it's only a hybrid Tcl/Tk+C application, rather than a
hybrid Tcl/Tk+C+libraster application.

> and I can begin to start working toward that goal.
> 
> i.ortho.photo has been reorganized and much of the recoding has taken
> place, but the legacy curses still exists.  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, I
> know you have valid reservations, but I really believe this is the best
> approach from the user's perspective.
> 
> 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.

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.

A good example is gis.m's geo-rectifier. Interactive placement of GCPs
is done through the GUI, which then feeds the GCPs to i.rectify or
v.transform. If you can obtain the GCPs by other means, then you can
skip the GUI and just use i.rectify or v.transform directly. 
Similarly, if you don't have Tcl/Tk installed, i.rectify and
v.transform still work.

The main issue is to avoid locking up useful functionality inside an
application which can only be used interactively (and which can't even
be compiled without libraries which aren't inherently required for
non-interactive use).

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.

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