Hi,
may it be possible that 'd.legend' doesn't add
itself completely to the XDRIVER list?
I would like to use it with d.out.png but
I am not sure what to add to d.legend.
Markus
Markus Neteler wrote:
may it be possible that 'd.legend' doesn't add
itself completely to the XDRIVER list?
if(!use_mouse)
D_add_to_list(G_recreate_command()) ;
I.e. it should add itself to the list, unless you use the mouse for
placement (obviously, adding interactive commands such as
"d.legend -m ..." to the redraw list isn't a good idea).
One possibility is to modify the string returned by
G_recreate_command(), i.e. remove the -m switch and add an at= option
corresponding to the the position that was selected using the mouse.
Or just construct the command directly without using
G_recreate_command() at all ("d.barscale -m" does this). Although,
with this approach, if someone subsequently adds a new option or flag,
it's as likely as not that they'll overlook the need to add it to the
code which constructs the command line.
Also, I'll use this space to note that tcltkgrass should use a
terminal (or, at least, an output window) when runninng d.legend with
the -m switch, so that the instructions can be seen.
--
Glynn Clements <glynn.clements@virgin.net>
> may it be possible that 'd.legend' doesn't add
> itself completely to the XDRIVER list?if(!use_mouse)
D_add_to_list(G_recreate_command()) ;I.e. it should add itself to the list, unless you use the mouse for
placement (obviously, adding interactive commands such as
"d.legend -m ..." to the redraw list isn't a good idea).One possibility is to modify the string returned by
G_recreate_command(), i.e. remove the -m switch and add an at= option
corresponding to the the position that was selected using the mouse.Or just construct the command directly without using
G_recreate_command() at all ("d.barscale -m" does this).
right, use at=.
Part of the reason for not saving it to the command history (ala
d.barscale) was for debugging purposes. It was easy to make a lot of
tests and then just tweak the edge of the window to clear them all.
Hopefully that time is mostly past now. I'm a bit dubious about messing
with the command line by hand like d.barscale does, maybe if it could be
done with a common library function somehow as there are many display
modules that could use this and it's ugly.
d.text.freetype also suffers from this in a way (loss of stdin data),
d.text at least saves the input text to a tmp file to survive the
redraw. Also, I was hoping to use the mouse placement code from
d.barscale for d.text and d.text.freetype at some point, but it hasn't
happened yet.
Also, I'll use this space to note that tcltkgrass should use a
terminal (or, at least, an output window) when runninng d.legend with
the -m switch, so that the instructions can be seen.
Works for me, both 5.3 and 5.7.
Output to stderr should show up in the tcl window as you go, stdout once
the command is finished. (aside: possible way to test for finished
process??)
see
http://grass.itc.it/pipermail/grass-commit/2004-August/012248.html
d.zoom from the menu also dumps mouse instructions to the main term
window, which was confusing for a new Mac user here who is just using
the menu system and not even looking at the command line yet.
(esp. when trying to work it with a one button mouse!)
Hamish
Hamish wrote:
> Also, I'll use this space to note that tcltkgrass should use a
> terminal (or, at least, an output window) when runninng d.legend with
> the -m switch, so that the instructions can be seen.Works for me, both 5.3 and 5.7.
Output to stderr should show up in the tcl window as you go, stdout once
the command is finished.
The data from stdout will show up as the buffer is flushed, which will
occur if the buffer becomes full, if the application calls
fflush(stdout), or when it exits.
(aside: possible way to test for finished process??)
Yes; if the command is run with "open {| ...} r" rather than exec,
termination will result in EOF on the returned descriptor. However, if
you wanted the data to go to the terminal, you would need to
explicitly copy it; moreover, the application's stdout stream will
then be fully-buffered rather than line-buffered, which isn't much use
for interactive applications.
Hmm; maybe we should consider using "expect" for Tcl/Tk code ("expect"
is essentially tclsh with added pty support). OTOH, that would be yet
another dependency which most users probably don't already have; I
suppose that it would be better to ensure that programs which generate
interactive output (e.g. prompts) always send it to stderr.
Some other points:
1. The "output" window should use a monospaced font (e.g. courier); a
lot of stuff doesn't work quite right with a proportional font.
2. We should probably make some attempt at processing backspace
characters (i.e. deleting the previous character). Better still would
be to recognise the G_percent() sequences and display a progress bar.
--
Glynn Clements <glynn.clements@virgin.net>
A small interface note. The autogenerated tcltk dialog for d.legend
has a pulldown for the position coordinates. This pulldown (i.e.,
#%options-> value,value,...) only contains the entry 0-100. This is
also automatically entered in the field (i.e., #%answer->0-100). This
is an incorrect format that generates an error unless it is erased
each time d.legend is started.
I know. This is happens when there is "->options" specified but no
default value ("->answer"). Many of the other parameters have options
ranges (and therefore bounds checking) too, without harm. The at option
actually has "NULL" as the default answer. (default: automatic sizing)
d.barscale gets it right, but note it doesn't use D_color_list() so no
pull down menu for the colors. (cost of allowing R:G:B and "none")
opt->options is also unaware of opt->multiple=YES; I'd prefer to have
it be options: 0-100,0-100,0-100,0-100
and bounds checking on all inputs & an arg==4 check from that, although
sometimes it is useful to draw a bit beyond the edge of the screen.
This is another matter.
All other pulldowns, except color, have equally meaningless values.
No, the values listed in the other boxes are the default values.
See 'd.legend --help'. Having the default values filled in even if you
don't use them is harmless.
So the issue is that the value of "->options" shouldn't be placed in the
tcl input boxes, only the "->answer" (default) values. On the other hand
this works nicely when there is a default value (try the pull down menu
for another option to see).
FWIW, it might work better if the range option worked more like
the'required' option. That is, if a value for the entry was outside
the range, it would produce an interpretable error like "values for
<entry> must be within the range<range>".
It already does that, that's the point of "->options".
A couple questions about the full d.zoom command.
1) Is there any reason to put this in the menus? That is, does it do
anything that the 2 current menu entries (zoom in current window, and
zoom with pan in current window) don't accomplish?
-h handheld mode, probably mainly used via mouse/stylus input from the
menus and not entered on the command line from a tiny keyboard if you
can help it. I've never used -j, maybe it is useful too?
2) What does the zoom magnification do? It would be nice, I suppose,
to be able to zoom to a percentage rather than just using a mouse. But
I can't seem to get it to work.
How fast it unzooms.
3) We lost the pan function with the shift to GRASS 5.7. It would be
nice to get it back somehow.
'd.zoom -f' does it, having d.pan as well is just more code to
maintain for no additional functionality. I guess we could have 'd.zoom
-p' which goes into pan mode automatically and the menu could call that.
Perhaps a Zoom submenu which gives the three options:
- Zoom/Unzoom active display
- Pan and zoom active display
- Zoom with bells and whistles
which is a bit better placed than the current postition. As one of the
most used commands it shouldn't be right at the bottom of a long list.
maybe relegate "Pan&Zoom" to the bells and whistles one and have two
options in the submenu.
This might require adding --parser or --gui (like --html-description) to
force a GUI box when needed. I think this is what Glynn was considering?
--no-gui (or --cli) might be a useful control too.
I don't think d.zoom, d.redraw, d.erase should load GUIs by default, but
as they can take options sometimes it might be nice to be able to when
needed.
Hamish
Hamish,
Thanks for the explanation. A couple things a I still have questions on.
On 8/20/04 8:12 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
A small interface note. The autogenerated tcltk dialog for d.legend
has a pulldown for the position coordinates. This pulldown (i.e.,
#%options-> value,value,...) only contains the entry 0-100. This is
also automatically entered in the field (i.e., #%answer->0-100). This
is an incorrect format that generates an error unless it is erased
each time d.legend is started.I know. This is happens when there is "->options" specified but no
default value ("->answer"). Many of the other parameters have options
ranges (and therefore bounds checking) too, without harm. The at option
actually has "NULL" as the default answer. (default: automatic sizing)
For position coordinates, this causes an error even if you use the 'set
position with a mouse' flag. You are right, however, in that it does not
cause an error for the other fields. A NULL with automatic sizing would
actually be OK in the position coordinates if this worked.
d.barscale gets it right, but note it doesn't use D_color_list() so no
pull down menu for the colors. (cost of allowing R:G:B and "none")opt->options is also unaware of opt->multiple=YES; I'd prefer to have
it be options: 0-100,0-100,0-100,0-100
and bounds checking on all inputs & an arg==4 check from that, although
sometimes it is useful to draw a bit beyond the edge of the screen.
This is another matter.
Since this doesn't work, what is the best solution at present? Disable the
pulldown range checking or put a reasonable set of defaults in the answer->
field (e.g., 10, 20,10,90)?
All other pulldowns, except color, have equally meaningless values.
No, the values listed in the other boxes are the default values.
See 'd.legend --help'. Having the default values filled in even if you
don't use them is harmless.So the issue is that the value of "->options" shouldn't be placed in the
tcl input boxes, only the "->answer" (default) values. On the other hand
this works nicely when there is a default value (try the pull down menu
for another option to see).FWIW, it might work better if the range option worked more like
the'required' option. That is, if a value for the entry was outside
the range, it would produce an interpretable error like "values for
<entry> must be within the range<range>".It already does that, that's the point of "->options".
OK. It wasn't clear to me that it did anything. Now I understand that it
actually works.
A couple questions about the full d.zoom command.
1) Is there any reason to put this in the menus? That is, does it do
anything that the 2 current menu entries (zoom in current window, and
zoom with pan in current window) don't accomplish?-h handheld mode, probably mainly used via mouse/stylus input from the
menus and not entered on the command line from a tiny keyboard if you
can help it. I've never used -j, maybe it is useful too?2) What does the zoom magnification do? It would be nice, I suppose,
to be able to zoom to a percentage rather than just using a mouse. But
I can't seem to get it to work.How fast it unzooms.
This is unclear. The description suggests it will zoom and unzoom. I think
this would be more useful.
3) We lost the pan function with the shift to GRASS 5.7. It would be
nice to get it back somehow.'d.zoom -f' does it, having d.pan as well is just more code to
maintain for no additional functionality. I guess we could have 'd.zoom
-p' which goes into pan mode automatically and the menu could call that.Perhaps a Zoom submenu which gives the three options:
- Zoom/Unzoom active display
- Pan and zoom active display
- Zoom with bells and whistles
I can do this. It does make sense. To me, an even better set would be
-zoom/unzoom in active display
-pan in active display
-zoom with bells and whistles
which is a bit better placed than the current postition. As one of the
most used commands it shouldn't be right at the bottom of a long list.
Your point is well taken. I guess I thought the most used commands should be
at either end of the menu, but not in the middle. I did want to put erase
somewhat away from the other commands so that a user is less apt to hit it
by accident when searching for another command. How about if the zoom
submenu is at the top, followed by nviz, etc, and d.erase is at the bottom.
maybe relegate "Pan&Zoom" to the bells and whistles one and have two
options in the submenu.
I think it is better to have an easily accessible pan option in the submenu
than to bury it more in the 'zoom with options'
This might require adding --parser or --gui (like --html-description) to
force a GUI box when needed. I think this is what Glynn was considering?
--no-gui (or --cli) might be a useful control too.I don't think d.zoom, d.redraw, d.erase should load GUIs by default, but
as they can take options sometimes it might be nice to be able to when
needed.
I agree.
Neither d.erase nor d.redraw are set up to run through g_parser(). AFAICT,
d.redraw doesn't have any options anyway.
D.erase could be redone to have a dialog to specify redraw color--either by
adding the appropriate option-> code or by scripting. This would be handy
occasionally.
Michael
____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
Hamish wrote:
d.barscale gets it right, but note it doesn't use D_color_list() so no
pull down menu for the colors. (cost of allowing R:G:B and "none")
Maybe we should support opt->gisprompt="color". Then the Tcl/Tk
interface could have a button to display one of those fancy colour
selector dialogs (the sort that allocate the entire colour map in one
go).
For building a usable GUI, the more distinct data types, the better.
However, there is an issue with modularity here. E.g. d.mon should
have opt->gisprompt="monitor" for the start/stop/select/unlock
options. However, that would require the ability to read the
monitorcap file, which is currently part of libraster.
I suppose that we could have some form of extension mechanism, whereby
individual modules can register handlers for additional types. E.g.
d.mon would register a handler for the "monitor" type; the handler
would need libraster, but d.mon already needs libraster anyhow.
[On the subject of the monitorcap file, I have some menu.tcl changes
to build the start/stop/select monitors menus from the monitorcap
file, so any additional monitors will become available automatically.]
> All other pulldowns, except color, have equally meaningless values.
No, the values listed in the other boxes are the default values.
See 'd.legend --help'. Having the default values filled in even if you
don't use them is harmless.
A couple of modules initialise opt->answer dynamically (e.g. based
upon the current region or information stored on the selected
monitor). In that situation, if commands are remembered (scripting,
command history), there's a difference between omitting an option and
explicitly supplying the default value.
This might require adding --parser or --gui (like --html-description) to
force a GUI box when needed. I think this is what Glynn was considering?
Yes.
--no-gui (or --cli) might be a useful control too.
Ideally that shouldn't be necessary; if a command doesn't require any
options (i.e. it doesn't have any options, or they are all optional),
then the GUI should only be displayed if explicitly requested by e.g.
--gui.
However, the behaviour of d.what.rast, d.zoom etc (i.e. may or may not
require options, depending upon what's on the monitor) is potentially
problematic for scripts. If there doesn't happen to be anything on the
monitor (e.g. because a previous command failed), the script will just
sit there waiting for user input.
There should be an explicit flag meaning "act upon whatever is
displayed on the monitor, and fail if nothing is displayed". Arguably,
this flag should be necessary to obtain the current no-option
behaviour so that, when run without arguments, these programs always
display the GUI.
I don't think d.zoom, d.redraw, d.erase should load GUIs by default, but
as they can take options sometimes it might be nice to be able to when
needed.
d.erase and d.redraw shouldn't display dialogs when run without
arguments, but should from tcltkgrass (maybe d.erase should have two
menu entries; one uses the default colour, the other displays a
dialog). For the reason mentioned above, I think that d.zoom should
require an explicit flag to get the existing no-option behaviour.
--
Glynn Clements <glynn.clements@virgin.net>
Michael Barton wrote:
Neither d.erase nor d.redraw are set up to run through g_parser(). AFAICT,
d.redraw doesn't have any options anyway.
d.erase has one option, color=, but it only calls G_parser() if
argc>1, so running it without any arguments will use the default
setting rather than prompting the user for a value.
A few other commands behave similarly. Specifically:
$ find src -name main.c | xargs fgrep G_parser | grep 'if \?(argc'
src/display/d.erase/main.c: if (argc > 1 && G_parser(argc, argv))
src/display/d.extend/cmd/main.c: if(argc > 1 && G_parser(argc, argv))
src/display/d.measure/cmd/main.c: if (argc > 1 && G_parser(argc,argv))
src/display/d.pan/main.c: if (argc > 1 && G_parser(argc,argv))
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.
--
Glynn Clements <glynn.clements@virgin.net>
On 8/21/04 2:58 PM, "Glynn Clements" <glynn.clements@virgin.net> wrote:
Michael Barton wrote:
Neither d.erase nor d.redraw are set up to run through g_parser(). AFAICT,
d.redraw doesn't have any options anyway.d.erase has one option, color=, but it only calls G_parser() if
argc>1, so running it without any arguments will use the default
setting rather than prompting the user for a value.A few other commands behave similarly. Specifically:
$ find src -name main.c | xargs fgrep G_parser | grep 'if \?(argc'
src/display/d.erase/main.c: if (argc > 1 && G_parser(argc, argv))
src/display/d.extend/cmd/main.c: if(argc > 1 && G_parser(argc, argv))
src/display/d.measure/cmd/main.c: if (argc > 1 && G_parser(argc,argv))
src/display/d.pan/main.c: if (argc > 1 && G_parser(argc,argv))
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.
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)?
I'm not sure whether we are saying the same thing or the opposite. 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. 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).
Michael
--
Glynn Clements <glynn.clements@virgin.net>
____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
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@virgin.net>
> 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.
It is redundant & just more code to maintain. It would be much better to
just add a -p flag to d.zoom to launch the panning function from
'd.zoom -f' automatically. If you really want a d.pan, make it a
script/alias which just calls 'd.zoom -p'.
From memory, the code was a mess too. (or perhaps just my understanding
of it)
Hamish
> d.barscale gets it right, but note it doesn't use D_color_list() so
> no pull down menu for the colors. (cost of allowing R:G:B and
> "none")Maybe we should support opt->gisprompt="color". Then the Tcl/Tk
interface could have a button to display one of those fancy colour
selector dialogs (the sort that allocate the entire colour map in one
go).
see the Vector controls in 5.7's d.m. This returns colors as R:G:B, but
the user never sees that. That would make things harder for the color
blind of course..
However, the behaviour of d.what.rast, d.zoom etc (i.e. may or may not
require options, depending upon what's on the monitor) is potentially
problematic for scripts. If there doesn't happen to be anything on the
monitor (e.g. because a previous command failed), the script will just
sit there waiting for user input.
But you wouldn't use an interactive command in a script..
Well, maybe if you were building some sort of app., not just automation.
Hamish
>> A small interface note. The autogenerated tcltk dialog for d.legend
>> has a pulldown for the position coordinates. This pulldown (i.e.,
>> #%options-> value,value,...) only contains the entry 0-100. This is
>> also automatically entered in the field (i.e., #%answer->0-100).
>This> is an incorrect format that generates an error unless it is
>erased> each time d.legend is started.
>
> I know. This is happens when there is "->options" specified but no
> default value ("->answer"). Many of the other parameters have
> options ranges (and therefore bounds checking) too, without harm.
> The at option actually has "NULL" as the default answer. (default:
> automatic sizing)For position coordinates, this causes an error even if you use the
'set position with a mouse' flag. You are right, however, in that it
does not cause an error for the other fields. A NULL with automatic
sizing would actually be OK in the position coordinates if this
worked.
So it is a problem with the menu generation, not d.legend..
> d.barscale gets it right, but note it doesn't use D_color_list() so
> no pull down menu for the colors. (cost of allowing R:G:B and
> "none")
>
> opt->options is also unaware of opt->multiple=YES; I'd prefer to
> have it be options: 0-100,0-100,0-100,0-100
> and bounds checking on all inputs & an arg==4 check from that,
> although sometimes it is useful to draw a bit beyond the edge of the
> screen. This is another matter.Since this doesn't work, what is the best solution at present? Disable
the pulldown range checking or put a reasonable set of defaults in the
answer-> field (e.g., 10, 20,10,90)?
but that would disable any check for automatic sizing. (If you give it
specific coordinates, d.legend will assume you know what you are doing
and draw off the edge of the screen, eg. This can be useful sometimes.)
hmmm.
>> A couple questions about the full d.zoom command.
>>
>> 1) Is there any reason to put this in the menus? That is, does it
>do> anything that the 2 current menu entries (zoom in current window,
>and zoom with pan in current window) don't accomplish?
>
> -h handheld mode, probably mainly used via mouse/stylus input from
> the menus and not entered on the command line from a tiny keyboard
> if you can help it. I've never used -j, maybe it is useful too?
>
>
>> 2) What does the zoom magnification do? It would be nice, I
>suppose, to be able to zoom to a percentage rather than just using a
>mouse. But I can't seem to get it to work.
>
> How fast it unzooms.This is unclear. The description suggests it will zoom and unzoom. I
think this would be more useful.
I doesn't seem to work right (or have any meaning) when "zoom=" is >1,
so that doesn't help.
>> 3) We lost the pan function with the shift to GRASS 5.7. It would
>be> nice to get it back somehow.
>
> 'd.zoom -f' does it, having d.pan as well is just more code to
> maintain for no additional functionality. I guess we could have
> 'd.zoom-p' which goes into pan mode automatically and the menu could
> call that.
>
>
> Perhaps a Zoom submenu which gives the three options:
>
> - Zoom/Unzoom active display
> - Pan and zoom active display
> - Zoom with bells and whistlesI can do this. It does make sense. To me, an even better set would be
-zoom/unzoom in active display
-pan in active display
-zoom with bells and whistles
I agree.
> which is a bit better placed than the current postition. As one of
> the most used commands it shouldn't be right at the bottom of a long
> list.Your point is well taken. I guess I thought the most used commands
should be at either end of the menu, but not in the middle. I did want
to put erase somewhat away from the other commands so that a user is
less apt to hit it by accident when searching for another command. How
about if the zoom submenu is at the top, followed by nviz, etc, and
d.erase is at the bottom.
Having d.zoom at the bottom as it is now is fine once you know where to
look for it; which you'll figure out pretty quickly I suppose.
shrug
> maybe relegate "Pan&Zoom" to the bells and whistles one and have two
> options in the submenu.I think it is better to have an easily accessible pan option in the
submenu than to bury it more in the 'zoom with options'
Ok, I'll see about adding 'd.zoom -p' for this.
Hamish
A couple of modules initialise opt->answer dynamically (e.g. based
upon the current region or information stored on the selected
monitor). In that situation, if commands are remembered (scripting,
command history), there's a difference between omitting an option and
explicitly supplying the default value.
d.what.vect in 5.7 seems to do the right thing.
If you type: 'd.what.vect'
- If there is no vector displayed you get a GUI asking for one
- if there is one, it automatically goes into query mode
Hamish
On 8/22/04 8:31 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
A couple of modules initialise opt->answer dynamically (e.g. based
upon the current region or information stored on the selected
monitor). In that situation, if commands are remembered (scripting,
command history), there's a difference between omitting an option and
explicitly supplying the default value.d.what.vect in 5.7 seems to do the right thing.
Except, d.what.vect is partly broken--on Mac's at least.
If you type: 'd.what.vect'
- If there is no vector displayed you get a GUI asking for one
- if there is one, it automatically goes into query modeHamish
____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
This works for me if d.pan is problematic.
On 8/22/04 8:08 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Ok, I'll see about adding 'd.zoom -p' for this.
____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
> Ok, I'll see about adding 'd.zoom -p' for this.
This works for me if d.pan is problematic.
It isn't that it will be problematic; right now 5.3 is bloated with all
sorts of redundant and unused code. 5.7 gives us the opportunity to make
the source code lean, mean, and better organized. Any opportunity to
consolidate redundant code should be taken in my opinion. This doesn't
mean that we can't have a d.pan command, just that behind the scenes
the d.zoom code should do the work.
regards,
H
Except, d.what.vect is partly broken--on Mac's at least.
Bus error directly after first mouse click, correct?
(Needs to be compiled with debugging info and run though a debugger..)
It seems to fail without error (just exits) about 1 in 20 times on
Linux, but I don't know how to get it to fail consistently.
Hamish
> Ok, I'll see about adding 'd.zoom -p' for this.
done for 5.7. (code rearrangement from zoom.c more than anything else)
I figured out where the 'd.zoom zoom=' magnification option is useful:
in d.pan. I haven't added support for this in the new 'd.zoom -p' but
there isn't any reason someone couldn't.
Further cleanup of the d.zoom code still possible ...
Hamish
Hamish wrote:
> A couple of modules initialise opt->answer dynamically (e.g. based
> upon the current region or information stored on the selected
> monitor). In that situation, if commands are remembered (scripting,
> command history), there's a difference between omitting an option and
> explicitly supplying the default value.d.what.vect in 5.7 seems to do the right thing.
... for certain values of "right".
If you type: 'd.what.vect'
- If there is no vector displayed you get a GUI asking for one
- if there is one, it automatically goes into query mode
For consistency, I would prefer an explicit switch. With no arguments,
you always get a GUI. With the switch, you never get a GUI; if a
vector is displayed, it goes into query mode; if there isn't, you get
an error.
--
Glynn Clements <glynn.clements@virgin.net>