[GRASS5] d.legend and d.out.png

[Glynn Clements]

Michael Barton wrote:

> Any idea why d.pan doesn't work in GRASS 5.7 anymore? As per my recent
> discussion with Hamish, it would be nice to get this functioning again.

1. 5.7 needs a directory and Makefile for d.pan.

2. main.c needs to be updated to the new vector API, and the sites
stuff removed.

3. The 5.3 tree includes unused source files (box.c and mke_window.c);
either these need to be deleted, or the 5.7 Makefile will have to have
an explicit list of object files, otherwise 5.7 will try to compile
them (and fail).

I've already done 1 and 2, and the resulting d.pan seems to work OK. 
If someone tells me the preferred solution to point 3 (i.e. whether
the unused source files should be "cvs remove"d), I'll commit it.

> >     src/display/d.where/cmd/main.c:    if (argc > 1 && G_parser(argc,argv))
> >     src/display/d.info/main.c: if (argc > 1 && G_parser(argc, argv))
> >     src/general/g.version/main.c:    if (argc > 1 && G_parser(argc, argv))
> >     src/paint/Programs/p.chart/main.c:    if (argc > 1 && G_parser(argc, argv))
> > 
> > Personally, I think that the user should only be prompted if no
> > arguments are given but the program can't be run that way, i.e. if it
> > has at least one non-optional argument.
> 
> Then how do you get a dialog when you want it? For example, how do you get a
> gui dialog for d.erase if you want to select colors interactively (e.g., if
> you want to see what is available for a background color)?

Right now, you can't.

If the argc>1 test was removed, you would have to explicitly type e.g. 
"d.erase black" if you didn't want the dialog.

Given the extent to which people are used to typing just "d.erase" and
expecting it to erase the screen, changing it would probably be a
substantial nuisance (not to mention scripts which call d.erase
without arguments, e.g. d.redraw; if typing "d.redraw" resulted in a
dialog with a "color" field, it would probably be rather confusing).

Also, if you had to supply a color= option to bypass the dialog, there
wouldn't be any way to use the default colour (black in 5.3, white in
5.7, although someone might have changed DEFAULT_BG_COLOR in gis.h).

If G_parser() was changed so that it only displayed the dialog (or
prompted) if the program had at least one required argument, we could
remove the argc>1 test from the individual programs. Having done that,
we could then add a global --ui switch to G_parser().

My main point is that, in most of the cases where it makes a
difference, the individual modules explicitly work around the existing
behaviour by adding an argc>1 test.

> I'm not sure whether we are saying the same thing or the opposite.

The opposite, I think.

> But to be
> consistent across GRASS 5.7, it seems that all commands like this should go
> through g_parser() and generate the normal tcltk dialog if they are run
> without arguments.

Both approaches are consistent in some sense. One consistent approach
is that if no arguments are given, a dialog is displayed. Another
equally consistent approach is that, if sufficient arguments are
given, a dialog is never displayed.

Actually, there's yet another corner case: what if no arguments are
given to a program which accepts no arguments at all (not even
optional arguments)? Should you get a dialog with no option fields,
just the output window and the run/help/clear/close buttons?

With the former approach (zero arguments => dialog), consistency
requires that you do. Obviously, with the latter approach, you've
supplied sufficient arguments, so you don't.

BTW, regardless of how you handle the other cases, if a --ui switch is
implemented, it should always display a dialog, even for programs
which accept no arguments.

> If they are run with arguments, they should work without
> the dialog. In this case, it would also be good (as you or Hamish suggested)
> to have a -default or -nogui flag to run them in default mode without the
> dialog (e.g., d.erase -d [for default mode] would simply erase the screen to
> white).

The problem is that this changes long-standing behaviour (and in the
case of d.erase, for a very commonly-used command). Everyone who uses
these programs from the command line would need to adjust, and every
script which uses them would need to be re-written (not just those
supplied with GRASS, but also home-grown scripts).

For tcltkgrass, it wouldn't matter if no program ever displayed the
dialog unless an explicit switch was supplied, because tcltkgrass can
ensure that the switch is always supplied.

As a command-line user, my personal preference would be for programs
never to display a dialog (nor use prompting). If I forget to supply
an essential argument, I would prefer it if the command simply failed
(i.e. the same behaviour as traditional Unix commands).

In 5.3, if I overlook a required argument and it starts prompting, I
just hit Ctrl-C, run "command <help>", then try again. I haven't
really used 5.7 (apart from the Tcl/Tk stuff I've been doing
recently), but the same would apply there: if I got a dialog, I'd just
close it and try again from the command line.

-- 
Glynn Clements <glynn.clements at virgin.net>