[GRASS5] d.info: flag added for approximate screen scale

[Markus Neteler]

On Thu, Jan 05, 2006 at 03:19:55PM +0000, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > I have added a new flag to d.info to print the
> > approximate map scale in GRASS monitor. I know that
> > it's not very precise, but an approximate figure
> > is better than nothing:
> > 
> > Example:
> > 
> >  d.info -s
> >  Approximate map scale in GRASS monitor <x0> 1:11000
> > 
> > I remember that this was removed in GRASS 5 (not by me)
> 
> It was removed for a reason, namely that it relied upon a whole bunch
> of assumptions (e.g. you have X libraries installed, you are using X,
> the monitor being queried is XDRIVER, you know which X display the
> monitor is using, etc) which aren't guaranteed to be true.

As suggested: It could be made optional.
 
> > but IMHO a GIS should be able to give such information.
> 
> The driver protocol doesn't include the necessary support.

This is not clear to me. If I
- have the map extent in pixel
- have the dots per pixel of the monitor (ok, an approximation)

why cannot an *approximate* scale be given? How to all the
other GIS solve it?
 
> The feature relied upon assuming that you can find X display, querying
> the resolution of that display, and assuming that display is the one
> which the monitor is using.

The algorithm gives the name of the monitor. I agree that this
won't work if the monitor is shown on a different machine.
But I am sure that this could be tested as well beforehand.

> > The algorithm takes the monitor size, the map size within
> > the monitor and the screen resolution (x DPI and y DPI)
> > into account. The latter may not be precise, depending on
> > the X server software, video card or monitor. The 
> > figure is therefore given rounded.
> > 
> > It still needs to be make optional in the Makefile
> > in case of X absences. Hints for a test are welcome.
> 
> The configure script only determines which libraries are available. It
> cannot determine whether or not you want to use them. In the case of
> the d.info hack, it's entirely possible that you won't want it even if
> the X libraries are available on the build system (e.g. because you
> want to build a package for distribution, and don't want to include a
> version of d.info which simply won't run on systems without Xlib).

What about XDRIVER then?

neteler   3672     1  0 12:52 pts/6    00:00:03 /hardmnt/bartok0/ssi/software/cvsgrass61/dist.x86_64-unk
nown-linux-gnu/driver/XDRIVER x0        dev/fifo.1a dev/fifo.1b

/usr/sbin/lsof -p 3672 | grep libX11
XDRIVER 3672 neteler  mem    REG                9,0   922040  755424 /usr/X11R6/lib64/libX11.so.6.2

It's at least a similar case. I don't see in the Makefile that it
is optional (maybe I am wrong).

> > I hope the flag survives this time :-)
> 
> Not if I have anything to do with it.

OK, I can always extract it to a private module.

> The reasons for its removal remain valid. Primarily, the fact that it
> caused the d.info executable to have an Xlib dependency.

I have conditionalized upon X11 presence now.
Only the Makefile test fails surprisingly.

> The other
> problems don't matter so long as you don't use the -s switch.

Right. And there are a couple of other problems in GRASS which
I would like to see to be taken out - but I simply don't use
them.

Markus