Subject: d.rast.arrow does not save a line in the monitor history
Platform: GNU/Linux/i386
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: GRASS 6.1.cvs (2005)
Name: David Finlayson
d.rast.arrow does not appear to write a line in the monitor history. As a result, d.save, d.out.png (what else?) do not put the arrow command in their output.
I wonder if this is the reson that d.zoom does not work with d.rast.arrow? There is another bug (Tracking ID 2012) that may be related.
Subject: d.rast.arrow does not save a line in the monitor history
..
GRASS Version: GRASS 6.1.cvs (2005)
Name: David Finlayson
d.rast.arrow does not appear to write a line in the monitor history.
As a result, d.save, d.out.png (what else?) do not put the arrow
command in their output.
I wonder if this is the reson that d.zoom does not work with
d.rast.arrow? There is another bug (Tracking ID 2012) that may be
related.
d.rast.arrow isn't saved to the command history. Easy enough to add this
by putting this:
D_add_to_list(G_recreate_command());
towards the end of the main{} function in arrow.c.
Same with d.rast.num.
Any d.redraw type command depends on what is saved to the window's
command history list (see d.save). Sometimes this isn't what was entered
on the command line (eg d.text and d.barscale -m).
Another question:
Do the default fonts (romans et. al) have an arrow char built in?
(distant memory that they did?) If so we could use it with
R_text_rotation() to improve to a 360 degree resolution arrow drawing
for standard GRASS aspect maps and ANSWERS aspect maps instead of the
current 8-way ones... maybe freetype same-char compatibility issues.
Do the default fonts (romans et. al) have an arrow char built in?
(distant memory that they did?) If so we could use it with
R_text_rotation() to improve to a 360 degree resolution arrow drawing
for standard GRASS aspect maps and ANSWERS aspect maps instead of the
current 8-way ones... maybe freetype same-char compatibility issues.
Probably better to just define an arrow in polar coordinates and vary
theta. Easy enough to drop a new fn into arrow.c to do this.
Can you (or someone) add this to d.rast.arrow and d.rast.num so that a
display with these features can be output to a graphics file using
d.out.file? Are there any more commands (excluding mouse placement) that
need this?
With regard to mouse placement, it would be nice if when placing something
with a mouse (e.g. A scalebar), the coordinates could be read on the mouse
click and pasted into the coordinate field so that the feature could be
saved.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
From: Hamish <hamish_nospam@yahoo.com>
Date: Mon, 3 Oct 2005 18:27:24 +1300
To: Request Tracker <grass-bugs@intevation.de>
Cc: <grass5@grass.itc.it>
Subject: Re: [GRASS5] [bug #3704] (grass) d.rast.arrow does not save a line in
the monitor history
Subject: d.rast.arrow does not save a line in the monitor history
..
GRASS Version: GRASS 6.1.cvs (2005)
Name: David Finlayson
d.rast.arrow does not appear to write a line in the monitor history.
As a result, d.save, d.out.png (what else?) do not put the arrow
command in their output.
I wonder if this is the reson that d.zoom does not work with
d.rast.arrow? There is another bug (Tracking ID 2012) that may be
related.
d.rast.arrow isn't saved to the command history. Easy enough to add this
by putting this:
D_add_to_list(G_recreate_command());
towards the end of the main{} function in arrow.c.
Same with d.rast.num.
Any d.redraw type command depends on what is saved to the window's
command history list (see d.save). Sometimes this isn't what was entered
on the command line (eg d.text and d.barscale -m).
Another question:
Do the default fonts (romans et. al) have an arrow char built in?
(distant memory that they did?) If so we could use it with
R_text_rotation() to improve to a 360 degree resolution arrow drawing
for standard GRASS aspect maps and ANSWERS aspect maps instead of the
current 8-way ones... maybe freetype same-char compatibility issues.
Can you (or someone) add this to d.rast.arrow and d.rast.num so that a
display with these features can be output to a graphics file using
d.out.file?
Yes (eventually).
Are there any more commands (excluding mouse placement) that need
this?
Probably. I'm a bit conservative about going around giving every module
every feature just because we can.. I like to convince myself that it
wasn't written that way on purpose.
With regard to mouse placement, it would be nice if when placing
something with a mouse (e.g. A scalebar), the coordinates could be
read on the mouse click and pasted into the coordinate field so that
the feature could be saved.
d.barscale already does this. Try 'd.barscale -m' and then use d.save to
look at what was saved to the window command list.
Also the superior mouse placement code from d.barscale needs to be
ported to other modules, e.g. d.text.freetype.