On Oct 19, 2008, at 9:00 AM, <grass-dev-request@lists.osgeo.org> wrote:
Date: Sun, 19 Oct 2008 12:21:16 -0000
From: "GRASS GIS" <trac@osgeo.org>
Subject: [GRASS-dev] Re: [GRASS GIS] #339: d.mon doesn't work
(WinGrass commandline)
To: undisclosed-recipients:;
Message-ID: <051.5bcb64e263c6dacf3603355c263febd2@osgeo.org>
Content-Type: text/plain; charset="utf-8"
#339: d.mon doesn't work (WinGrass commandline)
---------------------------+------------------------------------------------
Reporter: schulzea | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: major | Milestone: 6.4.0
Component: default | Version: 6.3.0 RCs
Resolution: fixed | Keywords:
Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by glynn):
Replying to [comment:1 hamish]:
X monitors do not exist in native MS windows. You must use the GUI or
install the cygwin version.
Perhaps an #ifdef could be added to d.mon so the module reports
something to this effect rather than leave the user confused.
It might be better to just omit d.mon on Windows. The program itself
compiles fine, but as none of the drivers exist, there isn't much point in
d.mon existing.
I agree. Another thing might be to include some information along this line in the d.mon doc page. Something along the lines of...
'd.mon is the original visualization environment for GRASS and designed to work only with the X-Windows windowing interface system, widely used with Linux and Unix operating systems. X-Windows is an alternative to the Macintosh Aqua windowing interface and Microsoft's Windows windowing interface. To use X-Windows (and d.mon) with the Macintosh, it is necessary to install X-Windows from the Mac OS X system disk. To use X-Windows in a Microsoft Windows environment, it is necessary to install the Cygwin Unix emulation package that includes X-Windows.
The TclTk and wxPython GUI interfaces that are installed with GRASS provide an alternative visualization environment to d.mon, do not require X-Windows, and work on all widely used operating systems (including Linux, Unix, Mac, and Windows).'
Michael Barton wrote:
>> X monitors do not exist in native MS windows. You must use the GUI or
> install the cygwin version.
>>
>> Perhaps an #ifdef could be added to d.mon so the module reports
> something to this effect rather than leave the user confused.
>
> It might be better to just omit d.mon on Windows. The program itself
> compiles fine, but as none of the drivers exist, there isn't much
> point in
> d.mon existing.
I agree. Another thing might be to include some information along this
line in the d.mon doc page.
Well, if d.mon is disabled in Windows, its manual page would be
disabled along with it.
Something along the lines of...
'd.mon is the original visualization environment for GRASS and
designed to work only with the X-Windows windowing interface system,
widely used with Linux and Unix operating systems. X-Windows is an
alternative to the Macintosh Aqua windowing interface and Microsoft's
Windows windowing interface. To use X-Windows (and d.mon) with the
Macintosh, it is necessary to install X-Windows from the Mac OS X
system disk. To use X-Windows in a Microsoft Windows environment, it
is necessary to install the Cygwin Unix emulation package that
includes X-Windows.
Except that d.mon isn't specific to XDRIVER, nor is the lack of
monitors on Windows.
And AFAICT, the legacy display architecture was originally designed
for Tektronix 41xx (and similar) terminals; X support came later.
--
Glynn Clements <glynn@gclements.plus.com>
On Sun, 19 Oct 2008, Glynn Clements wrote:
Except that d.mon isn't specific to XDRIVER, nor is the lack of
monitors on Windows.
And AFAICT, the legacy display architecture was originally designed
for Tektronix 41xx (and similar) terminals; X support came later.
Yes I think so too - IIRC in the 1987 GRASS promotional video you see an example of GRASS being used with a standalone graphics terminal.
How about for GRASS 7 on all platforms, turning d.mon into a script that runs an image display program that initialises the image it displays from GRASS_PNGFILE and automatically refreshes the display when the file is modified? If the display program was simple (I guess a very simple cross-platform PNG viewer might not be too difficult to implement?) it could be included in the GRASS source code and would be convenient for people to use all their favourite non-interactive d.* commands without having to run the GUI.
If there was a bit more intelligence built into it (would need a d.mon server process running to communicate with the viewers I suppose) replacements for d.where and d.measure etc. could also be implemented.
Paul
On 20/10/08 09:44, Paul Kelly wrote:
On Sun, 19 Oct 2008, Glynn Clements wrote:
Except that d.mon isn't specific to XDRIVER, nor is the lack of
monitors on Windows.
And AFAICT, the legacy display architecture was originally designed
for Tektronix 41xx (and similar) terminals; X support came later.
Yes I think so too - IIRC in the 1987 GRASS promotional video you see an example of GRASS being used with a standalone graphics terminal.
How about for GRASS 7 on all platforms, turning d.mon into a script that runs an image display program that initialises the image it displays from GRASS_PNGFILE and automatically refreshes the display when the file is modified? If the display program was simple (I guess a very simple cross-platform PNG viewer might not be too difficult to implement?) it could be included in the GRASS source code and would be convenient for people to use all their favourite non-interactive d.* commands without having to run the GUI.
Just to add my 2 cents: I've successfully used gqview [1] in that manner, i.e. leaving it open and displaying map.png. It automatically updates the images when it changes. I bet there must be several other programs that do the same, so I don't think we really need to program anything. Maybe just offer a list of programs that users might consider.
Moritz
[1] http://gqview.sourceforge.net/
Moritz Lennert wrote:
>> Except that d.mon isn't specific to XDRIVER, nor is the lack of
>> monitors on Windows.
>>
>> And AFAICT, the legacy display architecture was originally designed
>> for Tektronix 41xx (and similar) terminals; X support came later.
>
> Yes I think so too - IIRC in the 1987 GRASS promotional video you see an
> example of GRASS being used with a standalone graphics terminal.
>
> How about for GRASS 7 on all platforms, turning d.mon into a script that
> runs an image display program that initialises the image it displays
> from GRASS_PNGFILE and automatically refreshes the display when the file
> is modified? If the display program was simple (I guess a very simple
> cross-platform PNG viewer might not be too difficult to implement?) it
> could be included in the GRASS source code and would be convenient for
> people to use all their favourite non-interactive d.* commands without
> having to run the GUI.
Just to add my 2 cents: I've successfully used gqview [1] in that
manner, i.e. leaving it open and displaying map.png. It automatically
updates the images when it changes. I bet there must be several other
programs that do the same, so I don't think we really need to program
anything. Maybe just offer a list of programs that users might consider.
Note that there's also visualisation/ximgview, which exists for this
purpose (although more as a proof-of-concept than anything).
One limitation of ximgview is that it only works for mmap()d BMP
files. The reason for this is so that it will never have to deal with
an incomplete file.
To use it:
export GRASS_PNGFILE=map.bmp
# create the file
d.erase
export GRASS_PNG_MAPPED=TRUE
export GRASS_PNG_READ=TRUE
ximgview map.bmp
Also, you can set:
export GRASS_NOTIFY="kill -USR1 `pidof ximgview`"
This will cause R_close_driver() to send a signal to ximgview to
update the display, rather than waiting for it to poll. In that
situation, pass percent=1 to ximgview (percent=0 causes a
divide-by-zero).
At present, this mechanism won't work on Windows as the support for
memory-mapped files in the PNG and cairo drivers is Unix-specific
(mmap()).
I have been thinking about writing something similar in wxPython. The
main issue is that without GRASS_PNG_MAPPED, the viewer needs to be
robust against incomplete image files, and I don't know if this is
true for the built-in image handlers.
--
Glynn Clements <glynn@gclements.plus.com>
On Mon, 20 Oct 2008, Glynn Clements wrote:
Moritz Lennert wrote:
How about for GRASS 7 on all platforms, turning d.mon into a script that
runs an image display program that initialises the image it displays
from GRASS_PNGFILE and automatically refreshes the display when the file
is modified? If the display program was simple (I guess a very simple
cross-platform PNG viewer might not be too difficult to implement?) it
could be included in the GRASS source code and would be convenient for
people to use all their favourite non-interactive d.* commands without
having to run the GUI.
Just to add my 2 cents: I've successfully used gqview [1] in that
manner, i.e. leaving it open and displaying map.png. It automatically
updates the images when it changes. I bet there must be several other
programs that do the same, so I don't think we really need to program
anything. Maybe just offer a list of programs that users might consider.
Note that there's also visualisation/ximgview, which exists for this
purpose (although more as a proof-of-concept than anything).
Ah yes - that's exactly the kind of thing I was thinking about.
One limitation of ximgview is that it only works for mmap()d BMP
files. The reason for this is so that it will never have to deal with
an incomplete file.
To use it:
export GRASS_PNGFILE=map.bmp
# create the file
d.erase
export GRASS_PNG_MAPPED=TRUE
export GRASS_PNG_READ=TRUE
ximgview map.bmp
Also, you can set:
export GRASS_NOTIFY="kill -USR1 `pidof ximgview`"
This will cause R_close_driver() to send a signal to ximgview to
update the display, rather than waiting for it to poll. In that
situation, pass percent=1 to ximgview (percent=0 causes a
divide-by-zero).
Something like the above wrapped up in a script called d.mon would I suspect go a reasonable way towards satisfying people looking for a quick-and-easy way of displaying a few maps.
Paul
Paul Kelly wrote:
> One limitation of ximgview is that it only works for mmap()d BMP
> files. The reason for this is so that it will never have to deal with
> an incomplete file.
>
> To use it:
>
> export GRASS_PNGFILE=map.bmp
> # create the file
> d.erase
> export GRASS_PNG_MAPPED=TRUE
> export GRASS_PNG_READ=TRUE
> ximgview map.bmp
>
> Also, you can set:
>
> export GRASS_NOTIFY="kill -USR1 `pidof ximgview`"
>
> This will cause R_close_driver() to send a signal to ximgview to
> update the display, rather than waiting for it to poll. In that
> situation, pass percent=1 to ximgview (percent=0 causes a
> divide-by-zero).
Something like the above wrapped up in a script called d.mon would I
suspect go a reasonable way towards satisfying people looking for a
quick-and-easy way of displaying a few maps.
Unfortunately, the environment settings can't easily be wrapped up
into a script (unless the script were to spawn a child shell).
A more realistic solution would be to print an error message along
with a link to a wiki page explaining the alternatives.
Better still would be the option to have d.* commands interact with
the GUI. This would be simpler if wxPython included bindings for the
wxClient and wxServer classes (DDE on Windows, TCP on Unix), but it
currently doesn't.
--
Glynn Clements <glynn@gclements.plus.com>