[GRASS5] Directions for next generation UI

GRASS GIS GRASS GIS developer
1

This has been an very productive discussion on how to proceed on developing
a new UI for GRASS. A sensible consensus seems to be developing that
includes 3 parallel sets of activities:

1. Make modifications to critical GRASS C-modules that will allow them to be
integrated much better into a new GUI
2. Enhance the current TclTk GUI to encourage and make use of the C-module
modifications and move in a direction of a new GUI look/function.
3. Begin developing one or more prototype next generation GUI¹s for GRASS.

I think this is a very good idea. Here are a few things that might start
this process.

***For step 1, we need to prioritize which modules need to be modified in
what way, and which are the most critical to modify first. Here is my list,
taken from Glynn's recent post. I'm open to suggestions about reprioritizing
or recategorizing.

-Can be used in GUI as is. Interactive terminal use not required. Modify,
but low priority:

display/d.barscale (accepts screen coordinate input)
display/d.geodesic (accepts coordinate input)
display/d.legend (accepts screen coordinate input)
display/d.path (accepts screen coordinate input)
display/d.rhumbline (accepts coordinate input)
display/d.text.freetype (accepts screen coordinate input)
display/d.what.rast (r.what can be used by GUI)
raster/r.profile (accepts coordinate input)

-Function probably absorbed into GUI. Won't be needed eventually. No need to
modify:

display/d.measure
display/d.where
display/d.zoom

-Needs to be modified to be used in GUI. High priority:

display/d.what.vect (need version like r.what that accepts coordinate input)
display/d.profile (needs to accept coordinate input)
display/d.rast.edit (needs to accept coordinate input)
raster/r.le/r.le.setup
lib/display

Enhance png driver and g.pnmcomp so that they can be used in new display
monitor.

display/d.nviz (needs to read maps in layer tree and more)

-Need GUI versions. May require special widget creation. High priority but
not sure what to do immediately.

raster/r.digit
vector/v.digit (merge r.digit and v.digit?)

imagery/i.ask (what is this?)
imagery/i.class
imagery/i.ortho.photo/photo.2image
imagery/i.ortho.photo/photo.2target
imagery/i.points
imagery/i.vpoints (merge i.points and v.points = i.points3)

***For step 2, we can do the following in TclTk. I'm happy to see what I can
do, but will need help.

Implement as much as possible of look/functionality of new UI design specs
in TclTk to accustom GRASS users to new UI.

Try to implement Glynn's idea about using pnm files and TclTk Canvases, to
move towards new display monitor. (This seems to be a good direction for Qt
also, at least)

Get all of GRASS on all platforms to the same version of TclTk. What about
8.4.10 with expanded widget set (e.g., incl. iwidgets, tclsqlite, etc.)?
This would require some update of NVIZ I think.

I posted the 1st draft UI design specs on my website for people to read and
comment on. Crischan and Trevor have already made some excellent comments.
Please feel free to view and comment. This would be better on a WIKI site.
I'm registered on the GRASS WIKI. Can I make a new 'area'? Or do I have to
ask someone about this?
<http://www.public.asu.edu/~cmbarton/files/grass_ui/UI_design_060102.tgz&gt;

***For set 3, Crischan Wygoda has started on a Qt prototype that people can
try out <http://crischan.net/q1&gt;\. It already has some very nice features
that would dovetail with the efforts and specs above. Bob Covill has started
a GTK prototype. I don't propose a 'competition'. We should systematicallly
evaluate the developing prototypes as to functionality, maintainability, and
conformance with design specs over the next month or so.

How does this sound for a way to proceed?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

2

On 1/3/06, Michael Barton <michael.barton@asu.edu> wrote:

This has been an very productive discussion on how to proceed on developing
a new UI for GRASS. A sensible consensus seems to be developing that
includes 3 parallel sets of activities:

1. Make modifications to critical GRASS C-modules that will allow them to be
integrated much better into a new GUI
2. Enhance the current TclTk GUI to encourage and make use of the C-module
modifications and move in a direction of a new GUI look/function.
3. Begin developing one or more prototype next generation GUI¹s for GRASS.

Just a note for users and interested developers. Development of GRASS plugin
for QGIS continues and it will continue in future even if it is not mentioned
in Michael's list. Users' response is very positive (QGIS IRC).

QGIS 0.8 will bring:
- location/mapset creation wizard
    http://mpa.itc.it/radim/qgis/newmapset4.png
    http://qgis.org/flash/flashwrapper.php?filename=grass_plugin1.swf
- mapset can be opened/closed from QGIS
- graphical inteface for mapcalc
    http://mpa.itc.it/radim/qgis/mapcalc.png
- many new tools in toolbox (import,network,interactive extraction,...)
- GRASS shell
    http://mpa.itc.it/radim/qgis/shell1.png

Radim

I think this is a very good idea. Here are a few things that might start
this process.

***For step 1, we need to prioritize which modules need to be modified in
what way, and which are the most critical to modify first. Here is my list,
taken from Glynn's recent post. I'm open to suggestions about reprioritizing
or recategorizing.

-Can be used in GUI as is. Interactive terminal use not required. Modify,
but low priority:

display/d.barscale (accepts screen coordinate input)
display/d.geodesic (accepts coordinate input)
display/d.legend (accepts screen coordinate input)
display/d.path (accepts screen coordinate input)
display/d.rhumbline (accepts coordinate input)
display/d.text.freetype (accepts screen coordinate input)
display/d.what.rast (r.what can be used by GUI)
raster/r.profile (accepts coordinate input)

-Function probably absorbed into GUI. Won't be needed eventually. No need to
modify:

display/d.measure
display/d.where
display/d.zoom

-Needs to be modified to be used in GUI. High priority:

display/d.what.vect (need version like r.what that accepts coordinate input)
display/d.profile (needs to accept coordinate input)
display/d.rast.edit (needs to accept coordinate input)
raster/r.le/r.le.setup
lib/display

Enhance png driver and g.pnmcomp so that they can be used in new display
monitor.

display/d.nviz (needs to read maps in layer tree and more)

-Need GUI versions. May require special widget creation. High priority but
not sure what to do immediately.

raster/r.digit
vector/v.digit (merge r.digit and v.digit?)

imagery/i.ask (what is this?)
imagery/i.class
imagery/i.ortho.photo/photo.2image
imagery/i.ortho.photo/photo.2target
imagery/i.points
imagery/i.vpoints (merge i.points and v.points = i.points3)

***For step 2, we can do the following in TclTk. I'm happy to see what I can
do, but will need help.

Implement as much as possible of look/functionality of new UI design specs
in TclTk to accustom GRASS users to new UI.

Try to implement Glynn's idea about using pnm files and TclTk Canvases, to
move towards new display monitor. (This seems to be a good direction for Qt
also, at least)

Get all of GRASS on all platforms to the same version of TclTk. What about
8.4.10 with expanded widget set (e.g., incl. iwidgets, tclsqlite, etc.)?
This would require some update of NVIZ I think.

I posted the 1st draft UI design specs on my website for people to read and
comment on. Crischan and Trevor have already made some excellent comments.
Please feel free to view and comment. This would be better on a WIKI site.
I'm registered on the GRASS WIKI. Can I make a new 'area'? Or do I have to
ask someone about this?
<http://www.public.asu.edu/~cmbarton/files/grass_ui/UI_design_060102.tgz&gt;

***For set 3, Crischan Wygoda has started on a Qt prototype that people can
try out <http://crischan.net/q1&gt;\. It already has some very nice features
that would dovetail with the efforts and specs above. Bob Covill has started
a GTK prototype. I don't propose a 'competition'. We should systematicallly
evaluate the developing prototypes as to functionality, maintainability, and
conformance with design specs over the next month or so.

How does this sound for a way to proceed?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

3

Michael Barton wrote:

-Needs to be modified to be used in GUI. High priority:

display/d.rast.edit (needs to accept coordinate input)

If you're referring to a program to allow you to modify raster cells
(i.e. map[x,y]=val) from the command-line, I think that's really a
completely different module (r.edit?).

[Doing this for individual cells is easy enough using r.mapcalc, but a
version which takes a file of x,y,val records might be useful.]

The existing d.rast.edit really falls into the "needs GUI version"
category, IMHO.

lib/display

Usage of R_get_location_with_* in lib/display comes down to three
functions:

int get_win_w_mouse() (get_win.c)

  Prompt the user to select a rectangular region using the mouse.
  Used by: d.frame

int ident_win() (ident_win.c)

  Select a "window" (aka "frame", as in d.frame) using the mouse.
  Used by: d.frame

D_popup() (popup.c)

  Create a popup menu on the monitor, return index of selected entry
  Used by: d.rast.edit, d.zoom

Regarding the first two, do we really need "frames"? I assume that
they date back to the use of graphics terminals (Tektronix 4105 etc)
before the advent of windowing systems meant that you could have
multiple monitor windows.

Which modules still use them? How many of those /don't/ fall into the
category of "needs GUI version"?

Regarding the third, d.rast.edit needs a standalone GUI version, and
d.zoom should be an integral feature of d.m.

Enhance png driver and g.pnmcomp so that they can be used in new display
monitor.

I don't think that any enhancements are strictly necessary (although
some might be useful).

BTW, you use the environment variable MONITOR_OVERRIDE to force a
display command to use a specific monitor regardless of the MONITOR
setting in $GISRC.

-Need GUI versions. May require special widget creation. High priority but
not sure what to do immediately.

raster/r.digit
vector/v.digit (merge r.digit and v.digit?)

imagery/i.ask (what is this?)

It appears to be a "map selector" dialog using the monitor. AFAICT,
it's only used by d.ask. IOW, similar to D_popup().

Get all of GRASS on all platforms to the same version of TclTk. What about
8.4.10 with expanded widget set (e.g., incl. iwidgets, tclsqlite, etc.)?
This would require some update of NVIZ I think.

I think that we should make a reasonable effort to support all recent
(8.x) versions of Tcl/Tk, without requiring too many add-ons. We need
to accept that compatibility issues may restrict which versions of
Tcl/Tk are suitable for NVIZ on some platforms. d.m should work with
whatever version the user needs to use for NVIZ.

--
Glynn Clements <glynn@gclements.plus.com>

4

As Gary pointed out, this will be a benefit to GRASS users, others, and for
further developing GRASS.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Radim Blazek <radim.blazek@gmail.com>
Date: Tue, 03 Jan 2006 12:10:34 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5 <grass5@grass.itc.it>
Subject: Re: [GRASS5] Directions for next generation UI

On 1/3/06, Michael Barton <michael.barton@asu.edu> wrote:

This has been an very productive discussion on how to proceed on developing
a new UI for GRASS. A sensible consensus seems to be developing that
includes 3 parallel sets of activities:

1. Make modifications to critical GRASS C-modules that will allow them to be
integrated much better into a new GUI
2. Enhance the current TclTk GUI to encourage and make use of the C-module
modifications and move in a direction of a new GUI look/function.
3. Begin developing one or more prototype next generation GUI¹s for GRASS.

Just a note for users and interested developers. Development of GRASS plugin
for QGIS continues and it will continue in future even if it is not mentioned
in Michael's list. Users' response is very positive (QGIS IRC).

QGIS 0.8 will bring:
- location/mapset creation wizard
    http://mpa.itc.it/radim/qgis/newmapset4.png
    http://qgis.org/flash/flashwrapper.php?filename=grass_plugin1.swf
- mapset can be opened/closed from QGIS
- graphical inteface for mapcalc
    http://mpa.itc.it/radim/qgis/mapcalc.png
- many new tools in toolbox (import,network,interactive extraction,...)
- GRASS shell
    http://mpa.itc.it/radim/qgis/shell1.png

Radim

I think this is a very good idea. Here are a few things that might start
this process.

***For step 1, we need to prioritize which modules need to be modified in
what way, and which are the most critical to modify first. Here is my list,
taken from Glynn's recent post. I'm open to suggestions about reprioritizing
or recategorizing.

-Can be used in GUI as is. Interactive terminal use not required. Modify,
but low priority:

display/d.barscale (accepts screen coordinate input)
display/d.geodesic (accepts coordinate input)
display/d.legend (accepts screen coordinate input)
display/d.path (accepts screen coordinate input)
display/d.rhumbline (accepts coordinate input)
display/d.text.freetype (accepts screen coordinate input)
display/d.what.rast (r.what can be used by GUI)
raster/r.profile (accepts coordinate input)

-Function probably absorbed into GUI. Won't be needed eventually. No need to
modify:

display/d.measure
display/d.where
display/d.zoom

-Needs to be modified to be used in GUI. High priority:

display/d.what.vect (need version like r.what that accepts coordinate input)
display/d.profile (needs to accept coordinate input)
display/d.rast.edit (needs to accept coordinate input)
raster/r.le/r.le.setup
lib/display

Enhance png driver and g.pnmcomp so that they can be used in new display
monitor.

display/d.nviz (needs to read maps in layer tree and more)

-Need GUI versions. May require special widget creation. High priority but
not sure what to do immediately.

raster/r.digit
vector/v.digit (merge r.digit and v.digit?)

imagery/i.ask (what is this?)
imagery/i.class
imagery/i.ortho.photo/photo.2image
imagery/i.ortho.photo/photo.2target
imagery/i.points
imagery/i.vpoints (merge i.points and v.points = i.points3)

***For step 2, we can do the following in TclTk. I'm happy to see what I can
do, but will need help.

Implement as much as possible of look/functionality of new UI design specs
in TclTk to accustom GRASS users to new UI.

Try to implement Glynn's idea about using pnm files and TclTk Canvases, to
move towards new display monitor. (This seems to be a good direction for Qt
also, at least)

Get all of GRASS on all platforms to the same version of TclTk. What about
8.4.10 with expanded widget set (e.g., incl. iwidgets, tclsqlite, etc.)?
This would require some update of NVIZ I think.

I posted the 1st draft UI design specs on my website for people to read and
comment on. Crischan and Trevor have already made some excellent comments.
Please feel free to view and comment. This would be better on a WIKI site.
I'm registered on the GRASS WIKI. Can I make a new 'area'? Or do I have to
ask someone about this?
<http://www.public.asu.edu/~cmbarton/files/grass_ui/UI_design_060102.tgz&gt;

***For set 3, Crischan Wygoda has started on a Qt prototype that people can
try out <http://crischan.net/q1&gt;\. It already has some very nice features
that would dovetail with the efforts and specs above. Bob Covill has started
a GTK prototype. I don't propose a 'competition'. We should systematicallly
evaluate the developing prototypes as to functionality, maintainability, and
conformance with design specs over the next month or so.

How does this sound for a way to proceed?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

5

I managed to get a display into a TclTk canvas. It's an ugly hack, but it
works. I can try to refine it.

I can put display management buttons across each monitor window top, but it
isn't much help unless there are display management tools to go with them
(mainly zoom, pan, and query). Any thoughts about how to implement these in
TclTk? Or is this where we need to update versions of d.zoom, d.what.x,
etc?

From: Glynn Clements <glynn@gclements.plus.com>
Date: Tue, 3 Jan 2006 17:11:06 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5 <grass5@grass.itc.it>
Subject: Re: [GRASS5] Directions for next generation UI

Michael Barton wrote:

-Needs to be modified to be used in GUI. High priority:

display/d.rast.edit (needs to accept coordinate input)

If you're referring to a program to allow you to modify raster cells
(i.e. map[x,y]=val) from the command-line, I think that's really a
completely different module (r.edit?).

Actually there is no r.edit. D.rast.edit is the module that let's you modify
cat values of individual cells, chosen with a mouse. It'd kind of misnamed.
R.edit would be more appropriate. If it took an x,y,val, I guess it could be
used in a GUI to the extent that any other of these modules could be. Though
a GUI version would be nicer.

[Doing this for individual cells is easy enough using r.mapcalc, but a
version which takes a file of x,y,val records might be useful.]

How do you do this from r.mapcalc when you need x and y to be geographic
coordinates?

The existing d.rast.edit really falls into the "needs GUI version"
category, IMHO.

lib/display

Usage of R_get_location_with_* in lib/display comes down to three
functions:

int get_win_w_mouse() (get_win.c)

Prompt the user to select a rectangular region using the mouse.
Used by: d.frame

int ident_win() (ident_win.c)

Select a "window" (aka "frame", as in d.frame) using the mouse.
Used by: d.frame

D_popup() (popup.c)

Create a popup menu on the monitor, return index of selected entry
Used by: d.rast.edit, d.zoom

Regarding the first two, do we really need "frames"? I assume that
they date back to the use of graphics terminals (Tektronix 4105 etc)
before the advent of windowing systems meant that you could have
multiple monitor windows.

D.frame is the only module that permits multi-map 'layouts' in GRASS (e.g.,
inset maps). It is kind of clunky, but pretty useful. It would be better to
have a nice GUI layout facility (with rulers, snap-to grids, etc) that works
with multiple monitors (ala Trevor's suggestion), but that is quite a bit of
work I suspect.

Which modules still use them? How many of those /don't/ fall into the
category of "needs GUI version"?

Regarding the third, d.rast.edit needs a standalone GUI version, and
d.zoom should be an integral feature of d.m.

See opening question.

Enhance png driver and g.pnmcomp so that they can be used in new display
monitor.

I don't think that any enhancements are strictly necessary (although
some might be useful).

This was following your suggestion. But you are correct in that they work OK
as is. Is there any way to bypass the need to write the display to a disk
file, then read it from file into a canvas or other monitor widget?

BTW, you use the environment variable MONITOR_OVERRIDE to force a
display command to use a specific monitor regardless of the MONITOR
setting in $GISRC.

Could you explain this. How is it different from d.mon select= ?

-Need GUI versions. May require special widget creation. High priority but
not sure what to do immediately.

raster/r.digit
vector/v.digit (merge r.digit and v.digit?)

imagery/i.ask (what is this?)

It appears to be a "map selector" dialog using the monitor. AFAICT,
it's only used by d.ask. IOW, similar to D_popup().

Get all of GRASS on all platforms to the same version of TclTk. What about
8.4.10 with expanded widget set (e.g., incl. iwidgets, tclsqlite, etc.)?
This would require some update of NVIZ I think.

I think that we should make a reasonable effort to support all recent
(8.x) versions of Tcl/Tk, without requiring too many add-ons. We need
to accept that compatibility issues may restrict which versions of
Tcl/Tk are suitable for NVIZ on some platforms. d.m should work with
whatever version the user needs to use for NVIZ.

We should at least be able to package an updated bwidgets with GRASS if
needed. I don't know what iwidgets needs. Tclsqlite would help if we make
sqlite the default dbms in the future. But by that time, we may have moved
on to a new UI platform.

--
Glynn Clements <glynn@gclements.plus.com>

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

6

Michael Barton wrote:

I managed to get a display into a TclTk canvas. It's an ugly hack, but it
works. I can try to refine it.

I can put display management buttons across each monitor window top, but it
isn't much help unless there are display management tools to go with them
(mainly zoom, pan, and query). Any thoughts about how to implement these in
TclTk?

To get the necessary mouse events:

  bind $canvas <ButtonPress-1> {...}
  bind $canvas <Motion> {...}
  bind $canvas <ButtonRelease-1> {...}

The rest of the code would look substantially like the programs which
are being replaced.

> [Doing this for individual cells is easy enough using r.mapcalc, but a
> version which takes a file of x,y,val records might be useful.]

How do you do this from r.mapcalc when you need x and y to be geographic
coordinates?

  out = if(abs(x()-$x)<ewres()/2 && abs(y()-$y)<nsres()/2,$val,in)

> Regarding the first two, do we really need "frames"? I assume that
> they date back to the use of graphics terminals (Tektronix 4105 etc)
> before the advent of windowing systems meant that you could have
> multiple monitor windows.

D.frame is the only module that permits multi-map 'layouts' in GRASS (e.g.,
inset maps). It is kind of clunky, but pretty useful. It would be better to
have a nice GUI layout facility (with rulers, snap-to grids, etc) that works
with multiple monitors (ala Trevor's suggestion), but that is quite a bit of
work I suspect.

My point is that the user can always just use multiple monitors
instead of multiple frames on a single monitor. The concept of frames
pre-dates X, when you only had one "monitor" (the graphic terminal).

>> Enhance png driver and g.pnmcomp so that they can be used in new display
>> monitor.
>
> I don't think that any enhancements are strictly necessary (although
> some might be useful).

This was following your suggestion. But you are correct in that they work OK
as is. Is there any way to bypass the need to write the display to a disk
file, then read it from file into a canvas or other monitor widget?

Currently, no. Is there any advantage to skipping that step?

> BTW, you use the environment variable MONITOR_OVERRIDE to force a
> display command to use a specific monitor regardless of the MONITOR
> setting in $GISRC.

Could you explain this. How is it different from d.mon select= ?

"d.mon select=..." changes the MONITOR setting in $GISRC, which
affects any programs run in the current session. The environment
variable MONITOR_OVERRIDE can be set on a per-process basis. E.g. if
d.m does "set $env(MONITOR_OVERRIDE) PNG", any d.* commands which it
runs will automatically use the PNG driver, while d.* commands run by
the user from the command line will use the active monitor.

Essentially, using MONITOR_OVERRIDE means that the user can use the
command line concurrently with d.m, without conflicts related to the
active monitor setting.

--
Glynn Clements <glynn@gclements.plus.com>

7

From: Glynn Clements <glynn@gclements.plus.com>
Date: Wed, 4 Jan 2006 14:56:18 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5 <grass5@grass.itc.it>
Subject: Re: [GRASS5] Directions for next generation UI

Michael Barton wrote:

I managed to get a display into a TclTk canvas. It's an ugly hack, but it
works. I can try to refine it.

I can put display management buttons across each monitor window top, but it
isn't much help unless there are display management tools to go with them
(mainly zoom, pan, and query). Any thoughts about how to implement these in
TclTk?

To get the necessary mouse events:

bind $canvas <ButtonPress-1> {...}
bind $canvas <Motion> {...}
bind $canvas <ButtonRelease-1> {...}

The rest of the code would look substantially like the programs which
are being replaced.

So this means a rewrite of the display management commands to work with
whatever UI platform we use...

[Doing this for individual cells is easy enough using r.mapcalc, but a
version which takes a file of x,y,val records might be useful.]

Yes it would. This might be best added to r.reclass, so that it takes a file
of x,y,val as well as cat=val.

Regarding the first two, do we really need "frames"? I assume that
they date back to the use of graphics terminals (Tektronix 4105 etc)
before the advent of windowing systems meant that you could have
multiple monitor windows.

D.frame is the only module that permits multi-map 'layouts' in GRASS (e.g.,
inset maps). It is kind of clunky, but pretty useful. It would be better to
have a nice GUI layout facility (with rulers, snap-to grids, etc) that works
with multiple monitors (ala Trevor's suggestion), but that is quite a bit of
work I suspect.

My point is that the user can always just use multiple monitors
instead of multiple frames on a single monitor. The concept of frames
pre-dates X, when you only had one "monitor" (the graphic terminal).

The problem is that you can't get saved graphic output that shows multiple
maps, legends, etc. in a set of arranged windows by arranging multiple
monitors. It would be better to do it the way Trevor suggests, but outside
of d.frame, this ability does not exist in GRASS at the moment.

Enhance png driver and g.pnmcomp so that they can be used in new display
monitor.

I don't think that any enhancements are strictly necessary (although
some might be useful).

This was following your suggestion. But you are correct in that they work OK
as is. Is there any way to bypass the need to write the display to a disk
file, then read it from file into a canvas or other monitor widget?

Currently, no. Is there any advantage to skipping that step?

It's just a bit faster and saves some space. The png/ppm monitor output runs
1+ Mb. It takes a few seconds to write that out, then more time to read it
in. We're talking seconds, but it still slower than the current display
because it has to write then read.

BTW, you use the environment variable MONITOR_OVERRIDE to force a
display command to use a specific monitor regardless of the MONITOR
setting in $GISRC.

Could you explain this. How is it different from d.mon select= ?

"d.mon select=..." changes the MONITOR setting in $GISRC, which
affects any programs run in the current session. The environment
variable MONITOR_OVERRIDE can be set on a per-process basis. E.g. if
d.m does "set $env(MONITOR_OVERRIDE) PNG", any d.* commands which it
runs will automatically use the PNG driver, while d.* commands run by
the user from the command line will use the active monitor.

Essentially, using MONITOR_OVERRIDE means that the user can use the
command line concurrently with d.m, without conflicts related to the
active monitor setting.

This sounds very handy. I'll remember it.

Michael

8

Michael Barton wrote:

>> I managed to get a display into a TclTk canvas. It's an ugly hack, but it
>> works. I can try to refine it.
>>
>> I can put display management buttons across each monitor window top, but it
>> isn't much help unless there are display management tools to go with them
>> (mainly zoom, pan, and query). Any thoughts about how to implement these in
>> TclTk?
>
> To get the necessary mouse events:
>
> bind $canvas <ButtonPress-1> {...}
> bind $canvas <Motion> {...}
> bind $canvas <ButtonRelease-1> {...}
>
> The rest of the code would look substantially like the programs which
> are being replaced.

So this means a rewrite of the display management commands to work with
whatever UI platform we use...

The commands in question are those which should be integrated into the
GUI, so inevitably they need to be written for the specific GUI
implementation.

If there is a substantial part of any of the commands which isn't tied
to a particular GUI, that can be made a stand-alone program (e.g. the
bulk of d.what.rast is provided by r.what; you just need to obtain the
coordinates with the mouse then run r.what).

One task which will need to be done for several of the built-in
commands is converting a "screen" (x,y) position to geographic
coordinates.

This should probably be a function in the GUI program itself, so that
you can (efficiently) provide a continuous display of the geographic
coordinates of the mouse cursor (you wouldn't want to have to run an
external program every time the mouse moves).

>>> [Doing this for individual cells is easy enough using r.mapcalc, but a
>>> version which takes a file of x,y,val records might be useful.]

Yes it would. This might be best added to r.reclass, so that it takes a file
of x,y,val as well as cat=val.

That's a very different task to what r.reclass does. r.reclass
constructs a reclass table, leaving the raster data untouched. A
program to modify the actual raster data wouldn't have anything
significant in common with r.reclass.

>>> Regarding the first two, do we really need "frames"? I assume that
>>> they date back to the use of graphics terminals (Tektronix 4105 etc)
>>> before the advent of windowing systems meant that you could have
>>> multiple monitor windows.
>>
>> D.frame is the only module that permits multi-map 'layouts' in GRASS (e.g.,
>> inset maps). It is kind of clunky, but pretty useful. It would be better to
>> have a nice GUI layout facility (with rulers, snap-to grids, etc) that works
>> with multiple monitors (ala Trevor's suggestion), but that is quite a bit of
>> work I suspect.
>
> My point is that the user can always just use multiple monitors
> instead of multiple frames on a single monitor. The concept of frames
> pre-dates X, when you only had one "monitor" (the graphic terminal).

The problem is that you can't get saved graphic output that shows multiple
maps, legends, etc. in a set of arranged windows by arranging multiple
monitors. It would be better to do it the way Trevor suggests, but outside
of d.frame, this ability does not exist in GRASS at the moment.

That's arguably something that's better left to higher-level tools.
E.g. if you implemented it in d.m, you would be able to move the
frames around with the mouse, toggle them on or off etc, without
having to redraw everything.

Also, if you were producing illustrations for publication, you would
normally want a PostScript/PDF file where vector graphics, text etc
were actually stored as such, rather than having been rasterised.
PostScript's text and vector rendering capabilities go far beyond
anything that GRASS' display architecture will ever provide. For that,
you would want each "component" (raster, legend, heading etc) as a
separate entity rather than all rendered into one raster image.

[BTW, the Tcl/Tk canvas widget has a built-in "postscript" command to
generate a PostScript representation of the contents of the canvas.]

>>>> Enhance png driver and g.pnmcomp so that they can be used in new display
>>>> monitor.
>>>
>>> I don't think that any enhancements are strictly necessary (although
>>> some might be useful).
>>
>> This was following your suggestion. But you are correct in that they work OK
>> as is. Is there any way to bypass the need to write the display to a disk
>> file, then read it from file into a canvas or other monitor widget?
>
> Currently, no. Is there any advantage to skipping that step?

It's just a bit faster and saves some space. The png/ppm monitor output runs
1+ Mb. It takes a few seconds to write that out, then more time to read it
in. We're talking seconds, but it still slower than the current display
because it has to write then read.

Reading/writing 1MB of data should be so fast you don't even notice
it. Converting the PPM file into whatever Tk uses internally may take
some time, but that isn't a step that can be circumvented. I would
expect the slowest step to be d.rast, which is slow whatever driver
you use.

--
Glynn Clements <glynn@gclements.plus.com>

9

From: Glynn Clements <glynn@gclements.plus.com>
Date: Wed, 4 Jan 2006 18:44:06 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5 <grass5@grass.itc.it>
Subject: Re: [GRASS5] Directions for next generation UI

Michael Barton wrote:

I managed to get a display into a TclTk canvas. It's an ugly hack, but it
works. I can try to refine it.

I can put display management buttons across each monitor window top, but it
isn't much help unless there are display management tools to go with them
(mainly zoom, pan, and query). Any thoughts about how to implement these in
TclTk?

To get the necessary mouse events:

bind $canvas <ButtonPress-1> {...}
bind $canvas <Motion> {...}
bind $canvas <ButtonRelease-1> {...}

The rest of the code would look substantially like the programs which
are being replaced.

So this means a rewrite of the display management commands to work with
whatever UI platform we use...

The commands in question are those which should be integrated into the
GUI, so inevitably they need to be written for the specific GUI
implementation.

If there is a substantial part of any of the commands which isn't tied
to a particular GUI, that can be made a stand-alone program (e.g. the
bulk of d.what.rast is provided by r.what; you just need to obtain the
coordinates with the mouse then run r.what).

One task which will need to be done for several of the built-in
commands is converting a "screen" (x,y) position to geographic
coordinates.

This should probably be a function in the GUI program itself, so that
you can (efficiently) provide a continuous display of the geographic
coordinates of the mouse cursor (you wouldn't want to have to run an
external program every time the mouse moves).

Right. I don't know how to do this in TclTk, but if done, then a zoom
function, for example, could be built by simply using the mouse geographic
coordinates to send new extents to g.region.

[Doing this for individual cells is easy enough using r.mapcalc, but a
version which takes a file of x,y,val records might be useful.]

Yes it would. This might be best added to r.reclass, so that it takes a file
of x,y,val as well as cat=val.

That's a very different task to what r.reclass does. r.reclass
constructs a reclass table, leaving the raster data untouched. A
program to modify the actual raster data wouldn't have anything
significant in common with r.reclass.

So a reclass table by coordinate rather than cat isn't feasible? What about
doing it for r.recode. I only mention these two modules because they accept
file input of a list of parameters for changing a map.

Regarding the first two, do we really need "frames"? I assume that
they date back to the use of graphics terminals (Tektronix 4105 etc)
before the advent of windowing systems meant that you could have
multiple monitor windows.

D.frame is the only module that permits multi-map 'layouts' in GRASS (e.g.,
inset maps). It is kind of clunky, but pretty useful. It would be better to
have a nice GUI layout facility (with rulers, snap-to grids, etc) that
works
with multiple monitors (ala Trevor's suggestion), but that is quite a bit
of
work I suspect.

My point is that the user can always just use multiple monitors
instead of multiple frames on a single monitor. The concept of frames
pre-dates X, when you only had one "monitor" (the graphic terminal).

The problem is that you can't get saved graphic output that shows multiple
maps, legends, etc. in a set of arranged windows by arranging multiple
monitors. It would be better to do it the way Trevor suggests, but outside
of d.frame, this ability does not exist in GRASS at the moment.

That's arguably something that's better left to higher-level tools.
E.g. if you implemented it in d.m, you would be able to move the
frames around with the mouse, toggle them on or off etc, without
having to redraw everything.

Also, if you were producing illustrations for publication, you would
normally want a PostScript/PDF file where vector graphics, text etc
were actually stored as such, rather than having been rasterised.
PostScript's text and vector rendering capabilities go far beyond
anything that GRASS' display architecture will ever provide. For that,
you would want each "component" (raster, legend, heading etc) as a
separate entity rather than all rendered into one raster image.

[BTW, the Tcl/Tk canvas widget has a built-in "postscript" command to
generate a PostScript representation of the contents of the canvas.]

I agree that this is better, just that it's additional programming. In the
interim, d.frame remains useable because you don't have to use a mouse (with
terminal interaction) to define the frames.

Enhance png driver and g.pnmcomp so that they can be used in new display
monitor.

I don't think that any enhancements are strictly necessary (although
some might be useful).

This was following your suggestion. But you are correct in that they work
OK
as is. Is there any way to bypass the need to write the display to a disk
file, then read it from file into a canvas or other monitor widget?

Currently, no. Is there any advantage to skipping that step?

It's just a bit faster and saves some space. The png/ppm monitor output runs
1+ Mb. It takes a few seconds to write that out, then more time to read it
in. We're talking seconds, but it still slower than the current display
because it has to write then read.

Reading/writing 1MB of data should be so fast you don't even notice
it. Converting the PPM file into whatever Tk uses internally may take
some time, but that isn't a step that can be circumvented. I would
expect the slowest step to be d.rast, which is slow whatever driver
you use.

OK, I won't worry about it

--
Glynn Clements <glynn@gclements.plus.com>

10

Michael Barton wrote:

> One task which will need to be done for several of the built-in
> commands is converting a "screen" (x,y) position to geographic
> coordinates.
>
> This should probably be a function in the GUI program itself, so that
> you can (efficiently) provide a continuous display of the geographic
> coordinates of the mouse cursor (you wouldn't want to have to run an
> external program every time the mouse moves).

Right. I don't know how to do this in TclTk,

The arithmetic is all in lib/display/cnversions.c.

For the purposes of d.m, you should only need the D and U coordinate
systems, not the A system.

but if done, then a zoom function, for example, could be built by
simply using the mouse geographic coordinates to send new extents to
g.region.

Yep. Except that it might be useful to have a WIND_OVERRIDE variable
so that d.m could avoid modifying the WIND file. This would make it
easier to have multiple views with different zoom/pan, as well as
allowing you to run commands in the background without worrying about
the WIND file being changed.

The persistent state provided by $GISRC, the WIND file, monitor pads
etc, is useful for command-line usage, where you don't want to have to
pass a lot of parameters to every command, but are unnecessary (and an
obstacle) for a GUI application, which can maintain its own state, and
pass explicit settings to each command.

>>>>> [Doing this for individual cells is easy enough using r.mapcalc, but a
>>>>> version which takes a file of x,y,val records might be useful.]
>>
>> Yes it would. This might be best added to r.reclass, so that it takes a file
>> of x,y,val as well as cat=val.
>
> That's a very different task to what r.reclass does. r.reclass
> constructs a reclass table, leaving the raster data untouched. A
> program to modify the actual raster data wouldn't have anything
> significant in common with r.reclass.

So a reclass table by coordinate rather than cat isn't feasible? What about
doing it for r.recode. I only mention these two modules because they accept
file input of a list of parameters for changing a map.

r.recode is a better fit, as it actually generates a new raster array.
But that's a side issue; everyone seems to have managed to get by so
far without an r.edit module having been available.

>> The problem is that you can't get saved graphic output that shows multiple
>> maps, legends, etc. in a set of arranged windows by arranging multiple
>> monitors. It would be better to do it the way Trevor suggests, but outside
>> of d.frame, this ability does not exist in GRASS at the moment.
>
> That's arguably something that's better left to higher-level tools.
> E.g. if you implemented it in d.m, you would be able to move the
> frames around with the mouse, toggle them on or off etc, without
> having to redraw everything.
>
> Also, if you were producing illustrations for publication, you would
> normally want a PostScript/PDF file where vector graphics, text etc
> were actually stored as such, rather than having been rasterised.
> PostScript's text and vector rendering capabilities go far beyond
> anything that GRASS' display architecture will ever provide. For that,
> you would want each "component" (raster, legend, heading etc) as a
> separate entity rather than all rendered into one raster image.
>
> [BTW, the Tcl/Tk canvas widget has a built-in "postscript" command to
> generate a PostScript representation of the contents of the canvas.]

I agree that this is better, just that it's additional programming. In the
interim, d.frame remains useable because you don't have to use a mouse (with
terminal interaction) to define the frames.

After mouse input, "pads" (property lists used to store information
within the driver) would be the next thing to go. As frames are
essentially just rectangles stored in an pad, frames would go too.

[The reason for eliminating pads is that they amount to state which
persists between display commands; persistent state belongs in the GUI
alone. Ultimately, the display architecture should be nothing more
than a library which can be used by display commands to generate
graphics.]

With regard to adding display views to d.m, it would be worth
organising code in such a way that views can exist anywhere within the
widget hierarchy, rather than e.g. assuming a 1:1 correspondence
between toplevel windows and display views.

You don't actually need to provide the functionality to create
arbitrary layouts of views, just ensure that any code which maintains
a view doesn't make unwarranted assumptions about its position in the
widget hierarchy.

--
Glynn Clements <glynn@gclements.plus.com>