[GRASS-dev] Re: not quite there on fonts

[Glynn Clements]

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):

 imagery/i.vpoints/drawcell.c                  | D_new_window
 imagery/i.vpoints/drawvect.c                  | D_new_window
 raster/r.le/r.le.setup/main.c                 | D_new_window
 raster/r.le/r.le.trace/main.c                 | D_new_window
 display/d.profile/main.c                      | D_new_window_percent
 display/d.frame/create.c                      | D_new_window_percent

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

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