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.
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).
> 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.
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.
--
Glynn Clements <glynn@gclements.plus.com>