[GRASS-dev] Exit code for Tk GUI

Maris Nartiss maris.gis at gmail.com
Sun Sep 23 13:35:32 EDT 2007


Hi folks,

I was looking at open issue list and noted some interesting issue #483
[1]. It seemed to be easy to fix, but after some hours of digging into
code, it started to look like unfixable.

As I'm not a good programmer, please, correct me at any place where I'm wrong.

First - I understood that current GRASS autogenerated tcl/tk GUI works
in following way (with respect to exit codes and with shortenings):
1) module (i.e. r.info) is launched and control is passed to G_parser;
2) as there are no args, G_parser builds tcl/tk description for module
and passes it to wish (via popen and fprintf);
3) when user hits RUN button in module GUI, another instance of module
gets launched with users provided args via gronsole;
4) when user closes GUI, control is returned to G_parser;
5) G_parser returns error (-1) to caller;
6) module checks G_parser return code and exits as there was an error.

Final result == module with tcl interface allways exits with error.
It's a design failure. Returning other value from G_parser if user
just ended GUI session will break all modules that use G_parser (no-no
till GRASS7);

Still there may be some way around:
1) In G_gui_tcltk (parser.c) collect whole tcl/tk wish script (file,array) and
2) launch wish via execlp(getenv("GRASS_WISH"),script);
We get rid of first module instance that created GUI and exit code is
up to gis.tcl/gronsole.

Currently such approach has some problems:
1) if user hits RUN button in GUI w/o any param's, it starts another
module window (hint - need to look how parser determines that GUI is
already running);
2) still way how to get module exit code from gronsole is required.

Both issues could be worked around and then only one political
decision has to be made:
if user just launches module and closes it without running module - is
it a fail (1) or clean (0) exit?

Today I first time read about such things like exec, popen etc. and
now I'm too tired to see solutions how to finish dealing with this
bug, but I know that out there are lots of smart GRASS coders, that
could use my hints as starting point and also spot possible problems
before they appear.

Sorry for disturbance (and poor inglish),
Maris.




More information about the grass-dev mailing list