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

[Markus Neteler]

On Fri, Jan 06, 2006 at 11:19:50AM +0000, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > > > 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)
> 
> Which monitor?
> 
> Leaving aside the fact that different XDRIVER monitors could use
> different X servers, a single X server can use multiple monitors in a
> variety of configurations (multiple screens, Xinerama, duplication). 
> It can also use hardware other than monitors (e.g. projectors, for
> which you don't usually know the physical resolution).
> 
> And what makes you think there is a monitor? From the point that the
> hack was removed from d.info to the point it was re-introduced, d.info
> worked fine with the PNG driver on a system with no Xlib, no X server
> and no graphics hardware.
> 
> > why cannot an *approximate* scale be given? How to all the
> > other GIS solve it?
> 
> I don't have any experience with other GIS.
> 
> If d.info was interacting with the OS' display mechanism directly,
> rather than via the "monitor" abstraction, it could at least reliably
> determine the OS' opinion of the display resolution (that isn't likely
> to be accurate, but at least it would be consistent with other
> applications).
> 
> > > > 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).
> 
> XDRIVER inherently requires Xlib. If you don't have Xlib, you have no
> use for XDRIVER. But you may still have a use for d.info.

I assume that you did not look at d.info? The -s flag was only
compiled into *if* XLIB is present (#ifdefs in the C code).
In absence of XLIB the previous d.info was generated, just without
the -s flag.

I am still not sure if the XDRIVER is excluded from compilation if
XLIB is not available.

> The situation is very similar to the use of PostgreSQL in binary
> distributions of 5.3, i.e. including the pg.* modules but building
> NVIZ without PostgreSQL support.
> 
> > > > 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.
> 
> I would suggest that the changes aren't committed until they are done
> in such a way that they are harmless (i.e. can be disabled).

That was my last version.

> > > 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.
> 
> That's the wrong test. The issue isn't whether X is present on the
> build system, but whether it will be present on the target system, and
> you can't test for that.
> 
> Also, whether you want XDRIVER to be built and whether you want a
> version of d.info which simply won't run on a system without Xlib are
> two different things. In the former case, there is no significant
> difference between not building XDRIVER and building it even though
> you won't be able to use it. In the latter case, there /is/ a
> difference between building a version of d.info which works on all
> systems and building a version which only works on some systems.

Agreed.

Stuff removed in CVS.

> It would be best to avoid having to build GRASS twice for a binary
> distribution (build with X to get XDRIVER and NVIZ, build without X
> and replace d.info) for such a minor feature.

Can you explain this comment? For years we are distributing a single
GRASS version (at least for Linux).

Markus