[GRASS-dev] not quite there on fonts

H_B · May 15, 2007, 7:40am

> Hamish:
>>> ok, so bug #1977 still matters. (axes tags somewhat broken for FP
>>> maps)
>>> http://intevation.de/rt/webrt?serial_num=1977
>
> it only happens for some FP maps, for some window sizes.
>
> try: (spearfish)
> d.mon x0
> d.histogram slope
>
> then adjust the window size by grabbing the side of the frame.
> rinse & repeat.
>
> If I try that elevation.10m with a narrower window width the x units
> disappear altogether.

Michael:

But it is interesting that I can try all kinds of window geometry with
the display in wxgrass and the worst I get is that 1) the x-axis
numbers don't display (very skinny histogram) or 2) the font size of
the y-axis numbers and 1st x-axis number is larger than the size of
the rest of the x-axis numbers.

This is with output from the PNG driver.

In new Tcl GIS.m, add histogram button, mapname->slope@PARMANENT, redraw.
... Shows the overlapping numbers.

Hamish

cmbarton · May 15, 2007, 5:40pm

Ah. Slope IS really ugly.

Michael

On 5/15/07 12:40 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

In new Tcl GIS.m, add histogram button, mapname->slope@PARMANENT, redraw.
... Shows the overlapping numbers.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Paul_Kelly · May 15, 2007, 6:13pm

On Tue, 15 May 2007, Hamish wrote:

ok, so bug #1977 still matters. (axes tags somewhat broken for FP maps)
http://intevation.de/rt/webrt?serial_num=1977

I wonder is there a bit more too it that just the axes labelling. E.g. I tried comparing the output of "r.stats -c input=slope nsteps=10" to what d.histogram draws for nsteps=10. r.stats says:
0-5.252012 81333
5.252012-10.504024 86135
10.504024-15.756036 60593
15.756036-21.008047 37301
21.008047-26.260059 16918
26.260059-31.512071 6275
31.512071-36.764083 1415
36.764083-42.016095 139
42.016095-47.268107 13
47.268107-52.520119 1
* 12929

i.e. it seems obvious the first bar should cover the range 0-5.25012 and so on (although I think it's fine that the x-axis label shows whole numbers; it doesn't need to line up with the bar/bin edges), but in the d.histogram output it seems quite clear that the first bar is drawn between 5 and 10 (approximately) on the x-axis.

Also it seems strange that it doesn't allow you to set the number of bins for non-floating point maps.

Also, 255 bins seems not a very good default to me. It is a bit high and the result doesn't really look like a histogram.

I'll try and look into it more if I have time. Always remember doing maths at school and drawing a proper histogram being something that was really easy to get wrong!

Paul

Paul_Kelly · May 15, 2007, 10:04pm

On Tue, 15 May 2007, Paul Kelly wrote:

On Tue, 15 May 2007, Hamish wrote:

ok, so bug #1977 still matters. (axes tags somewhat broken for FP maps)
http://intevation.de/rt/webrt?serial_num=1977

I wonder is there a bit more too it that just the axes labelling. E.g. I tried comparing the output of "r.stats -c input=slope nsteps=10" to what d.histogram draws for nsteps=10. r.stats says:
0-5.252012 81333
5.252012-10.504024 86135
10.504024-15.756036 60593
15.756036-21.008047 37301
21.008047-26.260059 16918
26.260059-31.512071 6275
31.512071-36.764083 1415
36.764083-42.016095 139
42.016095-47.268107 13
47.268107-52.520119 1
* 12929

i.e. it seems obvious the first bar should cover the range 0-5.25012 and so on (although I think it's fine that the x-axis label shows whole numbers; it doesn't need to line up with the bar/bin edges), but in the d.histogram output it seems quite clear that the first bar is drawn between 5 and 10 (approximately) on the x-axis.

Actually, to put that another way you could say the numbers on the x-axis are in completely the wrong places. To me, it seems the numbers shown under the ticks refer to the floor'ed value (i.e. probably a double cast to an int) of the maximum value included in the bin to the right of the tickmark, if that makes sense. I.e. the numbers are one-off to the left of the ticks they represent, but even if shown under the correct tick they would still be wrong because they have been truncated to integers.

(Looking at the output of r.stats -c xxx nsteps=xx next to the histogram plot is really helpful for understanding this.)

I think the ticks should have no relation to the position of the borders between the bars. The left-hand edge of the first bar should start at the minimum value of the data and the right hand edge of the last bar should end at the maximum value of the data. I think round numbers in between should be marked with ticks (spacing worked out somehow from the hard-coded maximum 40 bins between numbered ticks).

That's probably easier to fix, than to put a more comprehensive fix in that would do the binning within d.histogram rather than relying on r.stats to do it all. Such a solution would enable the number of bins for integer maps to be specified too. At present this really doesn't seem possible without changing the structure of either d.histogram or r.stats.

Paul

Also it seems strange that it doesn't allow you to set the number of bins for non-floating point maps.

Also, 255 bins seems not a very good default to me. It is a bit high and the result doesn't really look like a histogram.

I'll try and look into it more if I have time. Always remember doing maths at school and drawing a proper histogram being something that was really easy to get wrong!

Paul

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

Paul_Kelly · May 16, 2007, 12:33pm

On Sun, 13 May 2007, Michael Barton wrote:

I'll play around with these. But maybe one of you can check to see if
d.histogram will actually accept some kind of background color change or if
it is hardcoded to white--so I don't waste a lot of time messing with this
in situation where it won't work.

FWIW, I was able to achieve my desired black background for the histogram plot through changing three things:
* Setting $GRASS_BACKGROUNDCOLOR to 000000 in gui/tcltk/gis.m/mapcanvas.tcl
* Changing D_setup(1); to D_setup(0); in display/d.histogram/main.c
* Removing the hardcoded "background=255:255:255" in the call to g.pnmcomp in gui/tcltk/gis.m/mapcanvas.tcl

It's hard to say which is the most important change - all were required -
after the first change the background originally started off black, but the D_setup(1); erased it to white. When I changed *that* so it didn't erase it to white first, but plotted the histogram on top of the black background, the output was still white. I think that was because it was transparent and the transparent parts were being made white by gis.m's call to the g.pnmcomp command. So I had to change it too.

Something worth looking at (as Hamish hinted) might be the way D_erase(1); erased to the hard-coded value of GRASS_BG_COLOR. As far as I can see there is no way to change this without re-compiling - kind of thwarting the purpose of it which was presumably to make it easier to change the default background colour? Maybe explicit use of DEFAULT_BG_COLOR and DEFAULT_FG_COLOR should be replaced by a call to a function which will override the hardcoded default values by (yet more) environment variables (if present)? I guess $GRASS_BACKGROUNDCOLOR could easily enough be used to override DEFAULT_BG_COLOR. I'm not sure of the implications though.

That's probably too much to change now though - an option to set the GRASS_BACKGROUNDCOLOR environment variable and removal of the hardcoded background=255:255:255 in the call to g.pnmcomp might be enough for now, if it doesn't mess up anything else. I've got the behaviour I wanted anyway. Regarding d.histogram though, I'm guessing the change to the erasing behaviour makes it now contradict the man page which explicitly says:
[...]
NOTES
[...]
d.histogram does not erase the active frame before displaying output.

Paul

Glynn_Clements1 · May 16, 2007, 2:07pm

Paul Kelly wrote:

> I'll play around with these. But maybe one of you can check to see if
> d.histogram will actually accept some kind of background color change or if
> it is hardcoded to white--so I don't waste a lot of time messing with this
> in situation where it won't work.

FWIW, I was able to achieve my desired black background for the histogram
plot through changing three things:
* Setting $GRASS_BACKGROUNDCOLOR to 000000 in gui/tcltk/gis.m/mapcanvas.tcl
* Changing D_setup(1); to D_setup(0); in display/d.histogram/main.c
* Removing the hardcoded "background=255:255:255" in the call to g.pnmcomp
in gui/tcltk/gis.m/mapcanvas.tcl

It's hard to say which is the most important change - all were required -
after the first change the background originally started off black, but
the D_setup(1); erased it to white. When I changed *that* so it didn't
erase it to white first, but plotted the histogram on top of the black
background, the output was still white. I think that was because it was
transparent and the transparent parts were being made white by gis.m's
call to the g.pnmcomp command. So I had to change it too.

Something worth looking at (as Hamish hinted) might be the way D_erase(1);
erased to the hard-coded value of GRASS_BG_COLOR. As far as I can see
there is no way to change this without re-compiling - kind of thwarting
the purpose of it which was presumably to make it easier to change the
default background colour? Maybe explicit use of DEFAULT_BG_COLOR and
DEFAULT_FG_COLOR should be replaced by a call to a function which will
override the hardcoded default values by (yet more) environment variables
(if present)? I guess $GRASS_BACKGROUNDCOLOR could easily enough be used
to override DEFAULT_BG_COLOR. I'm not sure of the implications though.

The least invasive change would be to add a flag to d.histogram to
inhibit erasing the background.

Beyond that, the frame stuff is all rather ugly. Arguably, it does too
much. It originated in the days of graphic terminals (Tek4105 etc);
much of it is unnecessary in an era of windowing systems.

Note that only 6 files actually create create new frames (not
including those which simply create the full_screen frame):

d.frame exists solely to create new frames, and the others are the
familiar "GUI built using libraster" cases.

--
Glynn Clements <glynn@gclements.plus.com>

cmbarton · May 16, 2007, 3:11pm

Maybe a stupid question, but can you give a histogram a blue or green
background? Changing certain functions give all PNG output a black
background, regardless of colors assigned. So it's possible that you still
aren't able to change the color of the histogram. Giving it something other
than white or black would definitely show that it's possible.

Michael

On 5/16/07 5:33 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

On Sun, 13 May 2007, Michael Barton wrote:

I'll play around with these. But maybe one of you can check to see if
d.histogram will actually accept some kind of background color change or if
it is hardcoded to white--so I don't waste a lot of time messing with this
in situation where it won't work.

FWIW, I was able to achieve my desired black background for the histogram
plot through changing three things:
* Setting $GRASS_BACKGROUNDCOLOR to 000000 in gui/tcltk/gis.m/mapcanvas.tcl
* Changing D_setup(1); to D_setup(0); in display/d.histogram/main.c
* Removing the hardcoded "background=255:255:255" in the call to g.pnmcomp
in gui/tcltk/gis.m/mapcanvas.tcl

It's hard to say which is the most important change - all were required -
after the first change the background originally started off black, but
the D_setup(1); erased it to white. When I changed *that* so it didn't
erase it to white first, but plotted the histogram on top of the black
background, the output was still white. I think that was because it was
transparent and the transparent parts were being made white by gis.m's
call to the g.pnmcomp command. So I had to change it too.

Something worth looking at (as Hamish hinted) might be the way D_erase(1);
erased to the hard-coded value of GRASS_BG_COLOR. As far as I can see
there is no way to change this without re-compiling - kind of thwarting
the purpose of it which was presumably to make it easier to change the
default background colour? Maybe explicit use of DEFAULT_BG_COLOR and
DEFAULT_FG_COLOR should be replaced by a call to a function which will
override the hardcoded default values by (yet more) environment variables
(if present)? I guess $GRASS_BACKGROUNDCOLOR could easily enough be used
to override DEFAULT_BG_COLOR. I'm not sure of the implications though.

That's probably too much to change now though - an option to set the
GRASS_BACKGROUNDCOLOR environment variable and removal of the hardcoded
background=255:255:255 in the call to g.pnmcomp might be enough for now,
if it doesn't mess up anything else. I've got the behaviour I wanted
anyway. Regarding d.histogram though, I'm guessing the change to the
erasing behaviour makes it now contradict the man page which explicitly
says:
[...]
NOTES
[...]
d.histogram does not erase the active frame before displaying output.

Paul

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

cmbarton · May 16, 2007, 3:26pm

I can probably write GUI code to make a nice histogram, using output from
r.stats. But Glynn's point about having GRASS tools available for scripting
is well taken. Also, it's a lot easier to simply call d.histogram than to
manually write the code to create a histogram.

Since you folks are looking at the guts of d.histogram, I should point out
that primitive as it is, it can create a couple of statistical graphs
(histogram and pie graph based on internal binning calculations), a bar
graph (what the histogram is actually drawing), and a pie graph. If it can
draw a bar graph, it can probably draw a line graph and scatter plot with
little additional work.

This could make it a fairly comprehensive internal graphing utility, with
limited but useful statistical capabilities, that could be applied to a
variety of tasks (e.g., displays from r.regression, several image processing
functions).

I don't know if it is worth the effort or not, but maybe it is worth
thinking about for a few minutes at least.

Michael

On 5/15/07 3:04 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

On Tue, 15 May 2007, Paul Kelly wrote:

On Tue, 15 May 2007, Hamish wrote:

ok, so bug #1977 still matters. (axes tags somewhat broken for FP maps)
http://intevation.de/rt/webrt?serial_num=1977

I wonder is there a bit more too it that just the axes labelling. E.g. I
tried comparing the output of "r.stats -c input=slope nsteps=10" to what
d.histogram draws for nsteps=10. r.stats says:
0-5.252012 81333
5.252012-10.504024 86135
10.504024-15.756036 60593
15.756036-21.008047 37301
21.008047-26.260059 16918
26.260059-31.512071 6275
31.512071-36.764083 1415
36.764083-42.016095 139
42.016095-47.268107 13
47.268107-52.520119 1
* 12929

i.e. it seems obvious the first bar should cover the range 0-5.25012 and so
on (although I think it's fine that the x-axis label shows whole numbers; it
doesn't need to line up with the bar/bin edges), but in the d.histogram
output it seems quite clear that the first bar is drawn between 5 and 10
(approximately) on the x-axis.

Actually, to put that another way you could say the numbers on the x-axis
are in completely the wrong places. To me, it seems the numbers shown
under the ticks refer to the floor'ed value (i.e. probably a double cast
to an int) of the maximum value included in the bin to the right of the
tickmark, if that makes sense. I.e. the numbers are one-off to the left
of the ticks they represent, but even if shown under the correct tick they
would still be wrong because they have been truncated to integers.

(Looking at the output of r.stats -c xxx nsteps=xx next to the histogram
plot is really helpful for understanding this.)

I think the ticks should have no relation to the position of the borders
between the bars. The left-hand edge of the first bar should start at the
minimum value of the data and the right hand edge of the last bar should
end at the maximum value of the data. I think round numbers in between
should be marked with ticks (spacing worked out somehow from the
hard-coded maximum 40 bins between numbered ticks).

That's probably easier to fix, than to put a more comprehensive fix in
that would do the binning within d.histogram rather than relying on
r.stats to do it all. Such a solution would enable the number of bins for
integer maps to be specified too. At present this really doesn't seem
possible without changing the structure of either d.histogram or r.stats.

Paul

Also it seems strange that it doesn't allow you to set the number of bins for
non-floating point maps.

Also, 255 bins seems not a very good default to me. It is a bit high and the
result doesn't really look like a histogram.

I'll try and look into it more if I have time. Always remember doing maths at
school and drawing a proper histogram being something that was really easy to
get wrong!

Paul

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Paul_Kelly · May 16, 2007, 3:56pm

On Wed, 16 May 2007, Michael Barton wrote:

Maybe a stupid question, but can you give a histogram a blue or green
background? Changing certain functions give all PNG output a black
background, regardless of colors assigned. So it's possible that you still
aren't able to change the color of the histogram. Giving it something other
than white or black would definitely show that it's possible.

Actually, good question. It appears I was a little hasty with my assumption of how it was working. On further investigation, it seems $GRASS_BACKGROUNDCOLOR is totally irrelevant if $GRASS_TRANSPARENT is set to true (because, obviously, the part that is background is transparent). So all the colour comes from the g.pnmcomp step. And it must have been black there because that is the default if the "background=" option is not specified. So the way to get a different coloured background is to put the desired background colour into the "background" field at the g.pnmcomp step, and make sure $GRASS_TRANSPARENT is true. And $GRASS_BACKGROUNDCOLOR is actually irrelevant when using transparency, it would seem.

(Of course this discussion assumes the change is also made to d.histogram not to erase the frame before it starts drawing. If it does erase it will pick up the hard-coded (in include/gis.h) GRASS_BG_COLOR which is white; in effect the whole frame will be filled with this colour and it will no longer be transparent..):

* Changing D_setup(1); to D_setup(0); in display/d.histogram/main.c

Actually in light of this I don't see any reason why not to change d.histogram back to the old behaviour. The worst that can happen is the histogram is drawn over a map already in a display, but all that needs done then is d.erase or d.frame -e and repeat the d.histogram command. But the big gain is a histogram plot with a transparent background. I'll make the change some time before too long if nobody objects. Or we could add a new flag that doesn't erase and always run it from the GUI with that flag set. I prefer the simplicity of just changing it back though (and thus restoring its behaviour to be in accordance with the man page).

Paul

cmbarton · May 16, 2007, 4:45pm

I'm happy with either one of these solutions. I can then add back in the
background color selection for histograms to wxgrass.

Michael

On 5/16/07 8:56 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Actually in light of this I don't see any reason why not to change
d.histogram back to the old behaviour. The worst that can happen is the
histogram is drawn over a map already in a display, but all that needs
done then is d.erase or d.frame -e and repeat the d.histogram command. But
the big gain is a histogram plot with a transparent background. I'll make
the change some time before too long if nobody objects. Or we could add a
new flag that doesn't erase and always run it from the GUI with that flag
set. I prefer the simplicity of just changing it back though (and thus
restoring its behaviour to be in accordance with the man page).

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Paul_Kelly · May 16, 2007, 8:52pm

Attached is a patch that seems to solve the worst of the d.histogram problems for me. I.e.
* the tick spacing is done correctly for large number of bins in a floating point map
* Range boundaries are calculated correctly (not off by one) and printed to 3 significant figures rather than being truncated to integers
* For integer maps the cell value covered by each bar is printed in the centre of the bar rather than to the left-hand side of it

But I haven't touched pie.c so it will only be fixed for bar graphs. And in general the code of the whole program is terribly convoluted and there could definitely be other subtle errors lurking in there I think. Also the text printing, ticks etc. could definitely be tidied up and made prettier.

But does it solve the problems others were having?

Paul

(attachments)

diff.txt (3.18 KB)

H_B · May 17, 2007, 6:20am

Paul Kelly wrote:

Actually in light of this I don't see any reason why not to change
d.histogram back to the old behaviour. The worst that can happen is
the histogram is drawn over a map already in a display, but all that
needs done then is d.erase or d.frame -e and repeat the d.histogram
command. But the big gain is a histogram plot with a transparent
background. I'll make the change some time before too long if nobody
objects. Or we could add a new flag that doesn't erase and always run
it from the GUI with that flag set. I prefer the simplicity of just
changing it back though (and thus restoring its behaviour to be in
accordance with the man page).

I would prefer to add a background color option to d.histogram, with a
default of DEFAULT_BG_COLOR and an option of "none".

Then remove the D_setup() clear flag and draw a rectangle of said color
(or none) that fills the window prior to anything else.

I will do this shortly. (bonus: color= -> RGB)

This doesn't solve the general problem of swapping DEFAULT_FG and
BG_COLOR without a recompile, unless you want all the xmon mapping done
that way.

But I think that d.histogram is the only non-mapping function left that
matters anymore:
d.profile is replaced by a much nicer Tcl version,
d.linegraph is better done using gnuplot's PS or SVG drivers
(+GhostScript/ svg2*).

so a module specific change isn't so bad.

I'll also fix the outdated reference in the man page.

Hamish

cmbarton · May 17, 2007, 6:32am

I'll try it out and see.

Michael

On 5/16/07 1:52 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Attached is a patch that seems to solve the worst of the d.histogram
problems for me. I.e.
* the tick spacing is done correctly for large number of bins in a
floating point map
* Range boundaries are calculated correctly (not off by one) and printed
to 3 significant figures rather than being truncated to integers
* For integer maps the cell value covered by each bar is printed in the
centre of the bar rather than to the left-hand side of it

But I haven't touched pie.c so it will only be fixed for bar graphs. And
in general the code of the whole program is terribly convoluted and there
could definitely be other subtle errors lurking in there I think. Also the
text printing, ticks etc. could definitely be tidied up and made prettier.

But does it solve the problems others were having?

Paul

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

H_B · May 17, 2007, 9:02am

Hamish wrote:

I would prefer to add a background color option to d.histogram, with a
default of DEFAULT_BG_COLOR and an option of "none".

Then remove the D_setup() clear flag and draw a rectangle of said
color (or none) that fills the window prior to anything else.

done. You'll have to make distclean as I added two new standard parser
opts for color= and bgcolor=.

d.histogram map=elevation.dem bgcolor=180:216:220
d.out.file histelev form=ps -r

While clearing the screen I couldn't erase the frame's d.save history
too, as that would clear the font setting in the PNG and PS drivers. :-/
(for d.out.file)

But I think that d.histogram is the only non-mapping function left
that matters anymore:
d.profile is replaced by a much nicer Tcl version,
d.linegraph is better done using gnuplot's PS or SVG drivers
(+GhostScript/ svg2*).

I forgot about d.polar.

Hamish

Paul_Kelly · May 17, 2007, 9:04am

On Thu, 17 May 2007, Hamish wrote:

I would prefer to add a background color option to d.histogram, with a
default of DEFAULT_BG_COLOR and an option of "none".

So using the "none" option means the transparency settings are respected? I suppose that's enough then, as long as that functionality is there. I was just thinking of some possible application where you might want to display the histogram transparently in some kind of widget box and you didn't know in advance what colour it would be, so need it transparent.

Paul

H_B · May 17, 2007, 10:23am

Paul Kelly wrote:

> I would prefer to add a background color option to d.histogram, with
> a default of DEFAULT_BG_COLOR and an option of "none".

So using the "none" option means the transparency settings are
respected? I suppose that's enough then, as long as that
functionality is there. I was just thinking of some possible
application where you might want to display the histogram
transparently in some kind of widget box and you didn't know in
advance what colour it would be, so need it transparent.

It should, insofar as it just draws new things to the screen without
blanking it first. But I haven't tested it with the g.pmncomp, just
overlaying it over already drawn maps in the xmon.

Hamish

cmbarton · May 17, 2007, 3:25pm

A general observation for parsing GRASS command strings into a GUI interface
using the xml generated by --interface-description.

It would be easier to parse colors if...
1) transparency could be an independent flag that overrides color selection
rather than be a color selection of "none". FWIW, it would be good if all
options that permitted a color to be set also permitted this feature to be
set to transparent too.
2) if all features which accept the small list of GRASS standard color
strings also accept color in rrr:ggg:bbb format (maybe this is already the
case?

Currently, many features (but not all) accept "none" as a color option, and
features that do accept "none" do not indicate it in a standard way for the
interface xml output. Requiring a single argument to accept either a color
string OR a transparency indicator is simple to deal with when typing (and
where the interface hints are irrelevant), but makes it much more difficult
to automatically popup an interactive color dialog AND try to deal with a
transparency option too.

Michael

On 5/16/07 11:20 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Paul Kelly wrote:

Actually in light of this I don't see any reason why not to change
d.histogram back to the old behaviour. The worst that can happen is
the histogram is drawn over a map already in a display, but all that
needs done then is d.erase or d.frame -e and repeat the d.histogram
command. But the big gain is a histogram plot with a transparent
background. I'll make the change some time before too long if nobody
objects. Or we could add a new flag that doesn't erase and always run
it from the GUI with that flag set. I prefer the simplicity of just
changing it back though (and thus restoring its behaviour to be in
accordance with the man page).

I would prefer to add a background color option to d.histogram, with a
default of DEFAULT_BG_COLOR and an option of "none".

Then remove the D_setup() clear flag and draw a rectangle of said color
(or none) that fills the window prior to anything else.

I will do this shortly. (bonus: color= -> RGB)

This doesn't solve the general problem of swapping DEFAULT_FG and
BG_COLOR without a recompile, unless you want all the xmon mapping done
that way.

But I think that d.histogram is the only non-mapping function left that
matters anymore:
d.profile is replaced by a much nicer Tcl version,
d.linegraph is better done using gnuplot's PS or SVG drivers
(+GhostScript/ svg2*).

so a module specific change isn't so bad.

I'll also fix the outdated reference in the man page.

Hamish

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

cmbarton · May 17, 2007, 3:30pm

On 5/16/07 11:20 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

But I think that d.histogram is the only non-mapping function left that
matters anymore:

This is because (unlike d.profile) d.histogram can be run in non-interactive
mode to generate graphics output.

d.profile is replaced by a much nicer Tcl version,
d.linegraph is better done using gnuplot's PS or SVG drivers
(+GhostScript/ svg2*).

I agree that d.linegraph is not a very nice or flexible way to create
graphs. The downside of this is it introduces an additional dependency if we
want a module to be able to display a graph. As a user, when I try to use a
tool that appears to be integral to a program, I find it very annoying to
discover that it won't work unless I install another piece of different
software. (This is different from an optional function that purports to
integrate 2 different pieces of software).

Michael

so a module specific change isn't so bad.

I'll also fix the outdated reference in the man page.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

cmbarton · May 17, 2007, 3:35pm

This is all nice. But I'm a bit confused at the moment as to what color
options are built into d.histogram and which require setting environmental
variables. I'll try to recompile today and try it out.

If there is a bg color setting built into the module now, this is a breeze
to set in the GUI--especially since it looks like the bg option will accept
rrr:ggg:bbb colors. The complications of transparency I mentioned in the
last post can simply be ignored with the assumption that we won't be showing
a histogram with anything other than a solid color background from the GUI.
Especially for wxpython, where a histogram shows up in a separate window,
transparency is irrelevant in this particular case.

Michael

On 5/17/07 2:04 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

On Thu, 17 May 2007, Hamish wrote:

I would prefer to add a background color option to d.histogram, with a
default of DEFAULT_BG_COLOR and an option of "none".

So using the "none" option means the transparency settings are respected?
I suppose that's enough then, as long as that functionality is there. I
was just thinking of some possible application where you might want to
display the histogram transparently in some kind of widget box and you
didn't know in advance what colour it would be, so need it transparent.

Paul

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton