[GRASS-dev] path.obstacles

[Daniel Calvelo]

On 4/27/07, Paul Kelly <paul-grass at stjohnspoint.co.uk> wrote:
[...]
>
> I think looking at d.path is the wrong way to go. We are moving away from
> the way modules like that interface with the display drivers directly, and
> more towards implementing interactive point-and-click display type stuff
> through a GUI. The idea being that the GUI detects where the user clicked,
> converts that into easting and northing and passes those co-ordinates
> directly to the command-line program (in this case v.path.obstacles) which
> it runs in the background and then displays the vector map output when
> finished, in another display. If you're not confident with GUI programming
> there are several other people working on it in GRASS now who could
> probably help with this. Have you explored gis.m much? As far as I know
> there are several places where it detects clicks on the Tk GUI canvas,
> converts those locations into eastings and northings and then runs an
> analysis with a command-line module. But I wouldn't worry about that too
> much at this stage - it can be added afterwards - much more important to
> get the command-line module working reliably and flexibly first.

Another way to look at it, if you feel adventurous, Maximilian: once
you have your base library and your GRASS-wrapped functions, create a
SWIG binding to the latter (ot both) then code the GUI in wxPython.

Your main GRASS module must be controllable exclusively by
command-line switches anyway. So I agree with Paul, leave the GUI work
for later and first concentrate on solid algorithms and user interface
through CLI.

Daniel.

-- 
-- Daniel Calvelo Aros