Dear grass users,
my question could be insane but I am wondering if there is an equivalent
command to d.mon in grass70.
In several man pages I saw a reference to d.frame but it seems not be
implemented yet.
Or will grass70 give up with x monitors ? considering one still can
launch grass in text mode, I guess there might be a way to open a
graphical device.
thank you for your commentaries on this question,
Vincent.
Vincent Bain wrote:
my question could be insane but I am wondering if there is an equivalent
command to d.mon in grass70.
In several man pages I saw a reference to d.frame but it seems not be
implemented yet.Or will grass70 give up with x monitors ? considering one still can
launch grass in text mode, I guess there might be a way to open a
graphical device.
GRASS 7.0 does not support monitors. The various display "drivers" are
libraries against which the display library is linked. There are no
persistent monitor processes as in 6.x, meaning that there is no
persistence of state between d.* commands, so no d.frame, d.font etc.
All rendering parameters are set via environment variables. Some of
these are listed in the "variables" manual page, while others are
listed in the manual pages for the various drivers.
You can approximate the pre-7.0 workflow using an image viewer which
automatically refreshes the display whenever the file changes. For X,
you can use the ximgview program, e.g.:
export GRASS_PNGFILE=map.bmp
d.erase
ximgview &
export GRASS_PNG_MAPPED=TRUE
export GRASS_PNG_READ=TRUE
# more d.* commands
--
Glynn Clements <glynn@gclements.plus.com>
Thank you for your answers and advices.
Glynn, with your method based on displaying grass files on the fly in a
viewer, I guess all d.* interactive commands will fail, won't they ?
Deep down I want to know how much I will have to adapt some shell
scripts I wrote for grass6* when my users migrate to grass70.
My feeling on this point with care for durability of the application -
and I think grass is mostly used by people in search of customization -
is it would be nice that be maintained these fundamentals... To my mind
it is one of the most important benefits of open source apps. On the
other hand I am not aware enough of the constraints that lead to drop x
monitors.
Bye,
Vincent
Le jeudi 03 décembre 2009 à 06:00 +0000, Glynn Clements a écrit :
Vincent Bain wrote:
> my question could be insane but I am wondering if there is an equivalent
> command to d.mon in grass70.
> In several man pages I saw a reference to d.frame but it seems not be
> implemented yet.
>
> Or will grass70 give up with x monitors ? considering one still can
> launch grass in text mode, I guess there might be a way to open a
> graphical device.GRASS 7.0 does not support monitors. The various display "drivers" are
libraries against which the display library is linked. There are no
persistent monitor processes as in 6.x, meaning that there is no
persistence of state between d.* commands, so no d.frame, d.font etc.All rendering parameters are set via environment variables. Some of
these are listed in the "variables" manual page, while others are
listed in the manual pages for the various drivers.You can approximate the pre-7.0 workflow using an image viewer which
automatically refreshes the display whenever the file changes. For X,
you can use the ximgview program, e.g.:export GRASS_PNGFILE=map.bmp
d.erase
ximgview &
export GRASS_PNG_MAPPED=TRUE
export GRASS_PNG_READ=TRUE
# more d.* commands
Vincent Bain wrote:
Glynn, with your method based on displaying grass files on the fly in a
viewer, I guess all d.* interactive commands will fail, won't they ?
There are no interactive d.* commands in 7.0.
The 7.0 display architecture doesn't have any facility to query a
mouse. Any modules which depended upon such functionality have either
been removed entirely or have had the corresponding functionality
removed.
Deep down I want to know how much I will have to adapt some shell
scripts I wrote for grass6* when my users migrate to grass70.My feeling on this point with care for durability of the application -
and I think grass is mostly used by people in search of customization -
is it would be nice that be maintained these fundamentals... To my mind
it is one of the most important benefits of open source apps.
This isn't going to change. If you want interaction, you need to
either extend the GUI, or leverage existing functionality (e.g. by
using the digitiser to create a vector map or the georectifier to
create GCPs, then using this data as input).
On the other hand I am not aware enough of the constraints that lead
to drop x monitors.
The interactive features made it impractical to build a decent GUI on
top of the display commands. Additionally, the monitor-based
architecture meant that it took an excessive amount of work to
implement relatively minor improvements, as well as making debugging
difficult. Oh, and none of it worked on Windows.
--
Glynn Clements <glynn@gclements.plus.com>
Thanks for your reply,
May I be considered bothersome, but was it really impossible to achieve
(like in grass65) the development of a wxGUI (which I really enjoy too)
while keeping the complete set of "historical" command line
environment ?
Le jeudi 03 décembre 2009 à 14:40 +0000, Glynn Clements a écrit :
Vincent Bain wrote:
> Glynn, with your method based on displaying grass files on the fly in a
> viewer, I guess all d.* interactive commands will fail, won't they ?There are no interactive d.* commands in 7.0.
The 7.0 display architecture doesn't have any facility to query a
mouse. Any modules which depended upon such functionality have either
been removed entirely or have had the corresponding functionality
removed.> Deep down I want to know how much I will have to adapt some shell
> scripts I wrote for grass6* when my users migrate to grass70.
>
> My feeling on this point with care for durability of the application -
> and I think grass is mostly used by people in search of customization -
> is it would be nice that be maintained these fundamentals... To my mind
> it is one of the most important benefits of open source apps.This isn't going to change. If you want interaction, you need to
either extend the GUI, or leverage existing functionality (e.g. by
using the digitiser to create a vector map or the georectifier to
create GCPs, then using this data as input).> On the other hand I am not aware enough of the constraints that lead
> to drop x monitors.The interactive features made it impractical to build a decent GUI on
top of the display commands. Additionally, the monitor-based
architecture meant that it took an excessive amount of work to
implement relatively minor improvements, as well as making debugging
difficult. Oh, and none of it worked on Windows.
Vincent Bain wrote:
May I be considered bothersome, but was it really impossible to achieve
(like in grass65) the development of a wxGUI (which I really enjoy too)
while keeping the complete set of "historical" command line
environment ?
Very little is actually impossible, but the disadvantages (in terms of
both effort and detriment to the end product) far outweigh the
advantages.
--
Glynn Clements <glynn@gclements.plus.com>
On Thu, 2009-12-03 at 18:59 +0000, Glynn Clements wrote:
Vincent Bain wrote:
> May I be considered bothersome, but was it really impossible to achieve
> (like in grass65) the development of a wxGUI (which I really enjoy too)
> while keeping the complete set of "historical" command line
> environment ?Very little is actually impossible, but the disadvantages (in terms of
both effort and detriment to the end product) far outweigh the
advantages.
I loved the "d.mon & co" tools ;-). But I understand that they had to be
dropped. Is there already something in the wiki (with respect to grass70
and interactive d.* tools)?
Thanks, Nikos