Following up on the discussions on the next generation GUI for GRASS, I’m working with several people on an interim GUI in TclTk that will begin to implement ideas in the UI roadmap. The idea is to enhance the current TclTk GUI so that display functions can increasingly be built into the GUI system rather than depending on d.* modules’ interactions with an x-display. We hope that this will encourage GRASS developers in general to modify GRASS display modules so that they do not require an x-display, and can be implemented in a wider variety of display/GUI systems.
My first step for TclTk has been to move GRASS map displays to a TclTk canvas, and create display management tools in TclTk. I’ve done this using the PNG driver, so it doesn’t depend on x11 for display. This has a number of advantages for usability (easier zooming and panning, constant display of geographic coordinates in an indicator window), seems faster for large maps, and has several nice features for continued development. One is direct printing to postcript (currently I’ve got a very simple version of this running with eps output). Another is the ability for each display to have it’s own layer tree and region settings (the next thing I’ll try to implement).
Basic raster querying is functioning, but vector query will need to await modification of d.what.vect to accept xy coordinates. I think that nviz displays in a canvas. If so, it could be better integrated in the new display system. To drop the xdriver completely would require changes to programs that require it for display—including v.digit and r.digit, d.rast.edit, d.profile, and i.points at least. For now, these can run by simply opening an x-display using d.mon. In the interim, we simply need to create a set of scripts or TclTk procedures that will automatically open (and hopefully close) the required x-monitor.
Please don’t hesitate to give the new prototype GIS Manager a try. To install, simply drop the gis.m script into $GISBASE/scripts and put the /gm folder into $GISBASE/etc. Then run gis.m & from the GRASS command line to start it. You’ll want to open a canvas display monitor, using the grey monitor button on the left.
Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
From: Wolf Bergenheim <wolf+grass@bergenheim.net>
Date: Wed, 11 Jan 2006 20:33:25 +0200
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5 <grass5@grass.itc.it>
Subject: Re: [GRASS5] prototype new GIS Manager in TclTk
I tested this gis.m I have to say that I am impressed. You have managed
to unclutter g.m! I have not used d.m since after week 2 of grass (I'm
a commandline kind of a guy), but this... Well I think I'm going to
start using it again, (;
GREAT job. Keep it up!
Then for a bugreport. Line 275 of cmonitor.tcl in gm refers to
"~/dispmon.ppm", but on line 255 you do:
set env(GRASS_PNGFILE) "dispmon.ppm"
This works in your home dir, but I usually switch to a subdirectory
where I can easily store output etc from grass in to the current
directory, so it didn't work... I know this is just a mock-up, but I
thought I'd point it out. Later probably it should be save in some
temporary dir that gets cleaned when you exit GRASS.
Thanks. I'll keep you and the list posted on fixes and updates.
I should also mention that Glynn Clements has been a great help in getting
me thought some critical spots in developing this.
Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
From: Wolf Bergenheim <wolf+grass@bergenheim.net>
Date: Wed, 11 Jan 2006 21:00:58 +0200
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5 <grass5@grass.itc.it>
Subject: Re: [GRASS5] prototype new GIS Manager in TclTk
Hi!
I tested this gis.m I have to say that I am impressed. You have managed
to unclutter g.m! I have not used d.m since after week 2 of grass (I'm
a commandline kind of a guy), but this... Well I think I'm going to
start using it again, (;
GREAT job. Keep it up!
Then for a bugreport. Line 275 of cmonitor.tcl in gm refers to
"~/dispmon.ppm", but on line 255 you do:
set env(GRASS_PNGFILE) "dispmon.ppm"
This works in your home dir, but I usually switch to a subdirectory
where I can easily store output etc from grass in to the current
directory, so it didn't work... I know this is just a mock-up, but I
thought I'd point it out. Later probably it should be save in some
temporary dir that gets cleaned when you exit GRASS.
Error in startup script: can't read "env(HOSTTYPE)": no such variable
while executing
"set HOSTTYPE $env(HOSTTYPE)"
(file "/usr/local/grass-6.1.cvs/etc/gm/gm.tcl" line 42)
just short
jachym
On Wed, Jan 11, 2006 at 10:56:19AM -0700, Michael Barton wrote:
Following up on the discussions on the next generation GUI for GRASS, I?m
working with several people on an interim GUI in TclTk that will begin to
implement ideas in the UI roadmap. The idea is to enhance the current TclTk
GUI so that display functions can increasingly be built into the GUI system
rather than depending on d.* modules? interactions with an x-display. We
hope that this will encourage GRASS developers in general to modify GRASS
display modules so that they do not require an x-display, and can be
implemented in a wider variety of display/GUI systems.
My first step for TclTk has been to move GRASS map displays to a TclTk
canvas, and create display management tools in TclTk. I?ve done this using
the PNG driver, so it doesn?t depend on x11 for display. This has a number
of advantages for usability (easier zooming and panning, constant display of
geographic coordinates in an indicator window), seems faster for large maps,
and has several nice features for continued development. One is direct
printing to postcript (currently I?ve got a very simple version of this
running with eps output). Another is the ability for each display to have
it?s own layer tree and region settings (the next thing I?ll try to
implement).
Basic raster querying is functioning, but vector query will need to await
modification of d.what.vect to accept xy coordinates. I think that nviz
displays in a canvas. If so, it could be better integrated in the new
display system. To drop the xdriver completely would require changes to
programs that require it for display‹including v.digit and r.digit,
d.rast.edit, d.profile, and i.points at least. For now, these can run by
simply opening an x-display using d.mon. In the interim, we simply need to
create a set of scripts or TclTk procedures that will automatically open
(and hopefully close) the required x-monitor.
Please don?t hesitate to give the new prototype GIS Manager a try. To
install, simply drop the gis.m script into $GISBASE/scripts and put the /gm
folder into $GISBASE/etc. Then run gis.m & from the GRASS command line to
start it. You'll want to open a canvas display monitor, using the grey
monitor button on the left.
Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
This is copied right out of the current dm file. Do you use the current d.m
gis manager?
Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
From: Jachym Cepicky <jachym.cepicky@centrum.cz>
Date: Wed, 11 Jan 2006 20:17:07 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5 <grass5@grass.itc.it>
Subject: Re: [GRASS5] prototype new GIS Manager in TclTk
hi,
Error in startup script: can't read "env(HOSTTYPE)": no such variable
while executing
"set HOSTTYPE $env(HOSTTYPE)"
(file "/usr/local/grass-6.1.cvs/etc/gm/gm.tcl" line 42)
just short
jachym
On Wed, Jan 11, 2006 at 10:56:19AM -0700, Michael Barton wrote:
Following up on the discussions on the next generation GUI for GRASS, I?m
working with several people on an interim GUI in TclTk that will begin to
implement ideas in the UI roadmap. The idea is to enhance the current TclTk
GUI so that display functions can increasingly be built into the GUI system
rather than depending on d.* modules? interactions with an x-display. We
hope that this will encourage GRASS developers in general to modify GRASS
display modules so that they do not require an x-display, and can be
implemented in a wider variety of display/GUI systems.
My first step for TclTk has been to move GRASS map displays to a TclTk
canvas, and create display management tools in TclTk. I?ve done this using
the PNG driver, so it doesn?t depend on x11 for display. This has a number
of advantages for usability (easier zooming and panning, constant display of
geographic coordinates in an indicator window), seems faster for large maps,
and has several nice features for continued development. One is direct
printing to postcript (currently I?ve got a very simple version of this
running with eps output). Another is the ability for each display to have
it?s own layer tree and region settings (the next thing I?ll try to
implement).
Basic raster querying is functioning, but vector query will need to await
modification of d.what.vect to accept xy coordinates. I think that nviz
displays in a canvas. If so, it could be better integrated in the new
display system. To drop the xdriver completely would require changes to
programs that require it for display‹including v.digit and r.digit,
d.rast.edit, d.profile, and i.points at least. For now, these can run by
simply opening an x-display using d.mon. In the interim, we simply need to
create a set of scripts or TclTk procedures that will automatically open
(and hopefully close) the required x-monitor.
Please don?t hesitate to give the new prototype GIS Manager a try. To
install, simply drop the gis.m script into $GISBASE/scripts and put the /gm
folder into $GISBASE/etc. Then run gis.m & from the GRASS command line to
start it. You'll want to open a canvas display monitor, using the grey
monitor button on the left.
Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
On Wed, January 11, 2006 20:17, Jachym Cepicky wrote:
hi,
Error in startup script: can't read "env(HOSTTYPE)": no such variable
while executing
"set HOSTTYPE $env(HOSTTYPE)"
(file "/usr/local/grass-6.1.cvs/etc/gm/gm.tcl" line 42)
I get the same on Debian testing/unstable. HOSTTYPE is set, though:
On Thu, Jan 12, 2006 at 11:03:17PM +0100, Moritz Lennert wrote:
On Wed, January 11, 2006 20:17, Jachym Cepicky wrote:
> hi,
>
> Error in startup script: can't read "env(HOSTTYPE)": no such variable
> while executing
> "set HOSTTYPE $env(HOSTTYPE)"
> (file "/usr/local/grass-6.1.cvs/etc/gm/gm.tcl" line 42)
I get the same on Debian testing/unstable. HOSTTYPE is set, though:
:~ > echo $HOSTTYPE
i486
Just commenting the line in gm/gm.tcl seems to cure the problem.
I've fixed this in the version I'm working on now. It was something put into
the mac version by Lorenzo. I did an if statement so that if hosttype is
not set, it simply goes on.
I've got each display to have its own region settings and near (I hope) to
getting each one to have its own layer tree (a stickier issue).
Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
From: Markus Neteler <neteler@itc.it>
Date: Thu, 12 Jan 2006 23:17:20 +0100
To: Moritz Lennert <mlennert@club.worldonline.be>
Cc: Jachym Cepicky <jachym.cepicky@centrum.cz>, Michael Barton
<michael.barton@asu.edu>, grass5 <grass5@grass.itc.it>
Subject: Re: [GRASS5] prototype new GIS Manager in TclTk
On Thu, Jan 12, 2006 at 11:03:17PM +0100, Moritz Lennert wrote:
On Wed, January 11, 2006 20:17, Jachym Cepicky wrote:
hi,
Error in startup script: can't read "env(HOSTTYPE)": no such variable
while executing
"set HOSTTYPE $env(HOSTTYPE)"
(file "/usr/local/grass-6.1.cvs/etc/gm/gm.tcl" line 42)
I get the same on Debian testing/unstable. HOSTTYPE is set, though:
:~ > echo $HOSTTYPE
i486
Just commenting the line in gm/gm.tcl seems to cure the problem.