[GRASS-user] grass70 and display monitor

[cmbarton]

Roy,

I guess you haven't been following quite all of this discussion.

You can still run all module commands in GRASS from any terminal. You can TYPE d* commands into the command line interface of the GUI and have the resulting maps displayed in the GUI display canvas. You can also type the d.* commands into any xterminal and have grass maps saved as graphic files to view. These can be viewed automatically with free image viewers (like d.mon did) as Glynn has shown. The old, primitive, INTERACTIVE xterminal behavior is all that has been dropped. For interactive use, there is a much more sophisticated interface that exists now--that is, you can do a lot more interaction than you could do before.

Besides simply not being GRASS 4 or 5 (which are still available to be run), what functionality are you missing?

Michael

On Dec 4, 2009, at 4:47 AM, grass-user-request@lists.osgeo.org wrote:

Date: Fri, 04 Dec 2009 08:29:46 +0000
From: Roy Sanderson <r.a.sanderson@newcastle.ac.uk>
Subject: Re: [GRASS-user] grass70 and display monitor
To: glynn@gclements.plus.com
Cc: grass-user@lists.osgeo.org
Message-ID: <1259915386.16719.126.camel@clarinet>
Content-Type: text/plain

Dear Glynn

I have been very surprised by the discussion on the Grass user lists
explaining the end of the d.mon and associated d.rast, d.vect commands
in the new Grass 7 version. I'd naively assumed that they were a
permanent feature of the Grass environment. From what I understand,
their phasing out is primarily because to retain them would impose
considerable technical challenges in a new Gui environment, would not
match the philosophy behind Gui interfaces, and provide little real
benefit.

My concern is simply that of an end-user, administering a small network
of Ubuntu PCs running Grass, because I have found it a considerable
struggle to persuade existing users to upgrade to each new version of
Grass. The proposed changes will undoubtedly make Grass more appealing
to new users, but long-term users will drag their feet. I notice that
even Microsoft is learning the hard way the risks of changing the user
interface too radically in an upgrade.

As way of contrast, R has kept a high degree of consistency of the
interface for each new version, such that existing users have no
problems when upgrading, but its command-line only environment causes
massive barriers for new users who are only familiar with Gui software.
Is Grass able to make some sort of compromise between improving the
interface to make it more appealing to new users, whilst bringing its
existing users with it?

Best wishes
Roy

--
Roy Sanderson
Institute for Research on Environment & Sustainability
Devonshire Building
Newcastle University
Newcastle upon Tyne NE1 7RU
r.a.sanderson@newcastle.ac.uk
0191 246 4835

[neteler]

On Fri, Dec 4, 2009 at 3:23 PM, Michael Barton <michael.barton@asu.edu> wrote:

Roy,

I guess you haven't been following quite all of this discussion.

Sincerely, I am in the same boat apparently, see below.

You can still run all module commands in GRASS from any terminal. You can
TYPE d* commands into the command line interface of the GUI and have the
resulting maps displayed in the GUI display canvas. You can also type the
d.* commands into any xterminal and have grass maps saved as graphic files
to view. These can be viewed automatically with free image viewers (like
d.mon did) as Glynn has shown. The old, primitive, INTERACTIVE xterminal
behavior is all that has been dropped.

And that's the key issue here.
Personally, I need (beside d.rast/d.vect)
- d.zoom
- d.measure
- d.where

to interactively work with the maps. GRASS analysis consists in my case
of a significant amount of graphically digging in the maps.

For interactive use, there is a much
more sophisticated interface that exists now--that is, you can do a lot more
interaction than you could do before.

True. But it is not yet as efficient as the old method. To better explain (and
please don't get me wrong, you have done a tremendous job with the new GUI!!,
note that I am one of these funky cmd line power users :-):
- to visualize a, say, raster map which I have been looking at 3 months ago,
I type in bash CTRL-R and a fraction of what I remember of the name, then maybe
another few CTRL-R to cycle to the right one. Enter and I see it.
- Using the GUI, I have to use the icon/find the menu entry, select
the map in the
  map selector (problem here, my MODIS LST time series have 5 * 1460 maps per
  mapset, that would be 7300 maps to scroll through!), then accept it
and have it
  listed in the map list. Still I don't see it because the "Render"
button isn't activated
  by default... (see my other poll about this some time ago). So, using the GUI
  here is unrealistic. Sure, I am a strange user

Besides simply not being GRASS 4 or 5 (which are still available to be run),
what functionality are you missing?

The speed of displaying maps and the ease of querying them. If there was a
command line possibility to control the wxGUI, I would most likely make
the switch to GRASS 7. Speed really matters for me. I am routinely analysing
11,000+ maps and regularly work in 3 projects in one morning, so the command
line history is a real lifesaver here to also recall what I have done
(and to eventually
morph it to a document).

The new GUI, integrated with the command line possibility to throw in the maps,
would be the perfect combination.

Markus

[cmbarton]

Markus,

This is helpful. Much more so than simply those that ask 'why can't we do things the way we did'.

Please see below.

On Dec 4, 2009, at 1:44 PM, Markus Neteler wrote:

On Fri, Dec 4, 2009 at 3:23 PM, Michael Barton <michael.barton@asu.edu> wrote:

Roy,

I guess you haven't been following quite all of this discussion.

Sincerely, I am in the same boat apparently, see below.

You can still run all module commands in GRASS from any terminal. You can
TYPE d* commands into the command line interface of the GUI and have the
resulting maps displayed in the GUI display canvas. You can also type the
d.* commands into any xterminal and have grass maps saved as graphic files
to view. These can be viewed automatically with free image viewers (like
d.mon did) as Glynn has shown. The old, primitive, INTERACTIVE xterminal
behavior is all that has been dropped.

And that's the key issue here.
Personally, I need (beside d.rast/d.vect)
- d.zoom
- d.measure
- d.where

Note for discussion below that these are not command line management of a display. Running any of these 'commands' only starts an interactive session the display. You already have to have something displayed in order to interact in this way. All three of these interactive functions are implemented in the GUI in ways that are almost identical to the way they were implemented before except for less need to use the right or middle mouse button.

to interactively work with the maps. GRASS analysis consists in my case
of a significant amount of graphically digging in the maps.

For interactive use, there is a much
more sophisticated interface that exists now--that is, you can do a lot more
interaction than you could do before.

True. But it is not yet as efficient as the old method. To better explain (and
please don't get me wrong, you have done a tremendous job with the new GUI!!,

Thanks.

note that I am one of these funky cmd line power users :-):
- to visualize a, say, raster map which I have been looking at 3 months ago,
I type in bash CTRL-R and a fraction of what I remember of the name, then maybe
another few CTRL-R to cycle to the right one. Enter and I see it.

OK. This important here. Especially if you have a lot of maps as you indicate below. What you are talking about is coming up with a map name using autocompletion. Note that it looks like autocompletion already may work in linux in the existing command entry box in the GUI. In the code is suggests that it is implemented but doesn't work on Mac. So I can't tell, but please try it and see.

More importantly, please try the patch I sent. If this seems like an improvement, there seem to be very sophisticated autocompletion and tool-tip functions in the styled text control that is used for the current CUI output window (my patch makes this simultaneously an input window, like a terminal). If this patch is helpful, we might be able to implement the kind of autocompletion you are talking about using code that Martin already has for the existing GUI. I have never coded autocompletion in this control, but I am guessing that we can have it look for "map=" or "input=" strings as the user types, check to see if these are raster or vector, and use a list of maps generated by g.list as input to the autocompletion.

- Using the GUI, I have to use the icon/find the menu entry, select
the map in the
map selector (problem here, my MODIS LST time series have 5 * 1460 maps per
mapset, that would be 7300 maps to scroll through!), then accept it
and have it
listed in the map list. Still I don't see it because the "Render"
button isn't activated
by default... (see my other poll about this some time ago). So, using the GUI
here is unrealistic. Sure, I am a strange user

All this is an issue about finding maps in a very long list. Important in your case, but it is a single issue and one that is potentially solvable in the architecture we now have.

Besides simply not being GRASS 4 or 5 (which are still available to be run),
what functionality are you missing?

The speed of displaying maps and the ease of querying them. If there was a
command line possibility to control the wxGUI, I would most likely make
the switch to GRASS 7.

But what is it you mean by control the GUI? I'm just trying to understand the functionality that you find missing. The commands that you mentioned above just start interactive sessions with the display. Such interaction required a mouse in GRASS 5 on up. They work much the same or better (i.e., they do more or give more information) now. Please tell us what other functions you feel are missing when you say control the GUI?

Speed really matters for me. I am routinely analysing
11,000+ maps and regularly work in 3 projects in one morning, so the command
line history is a real lifesaver here to also recall what I have done
(and to eventually
morph it to a document).

History is important. The output window already produces history that you can save. If you incorporate my patch, it also includes all display commands you run too (it already displays all other commands). Also, if you put your cursor on a command you typed in this history and press return it runs the command.

The new GUI, integrated with the command line possibility to throw in the maps,

Do you mean autocompletion to easily find the map you need? Also, what about the ability to type in the first few characters of a map name and have the scrolling map list jump to there? Many scrolling lists do that. I don't know what it would take to include this in the GRASS GUI, but if it is an important single feature, we could certainly try to implement it.

From this information, there seems to be only a single key missing feature for you. If there are more, please let us know so we can look into the feasibility of implementing them. Also, try out the existing command interface and check it's autocompletion feature to see if it is functional or not (Martin can offer input here too), and try the patch I sent to see if this makes life with the new GRASS easier.

Thanks for the input
Michael

[Vincent_Bain]

Le vendredi 04 décembre 2009 à 14:16 -0700, Michael Barton a écrit :

Markus,

This is helpful. Much more so than simply those that ask 'why can't we
do things the way we did'.

Michael,

as far as I am concerned by your remark, I just wish to distinguish my
attitude from that of a potential pure fastidious/demanding consumer : I
just keep very cautious from giving "advices" when I feel like being a
too modest contributor...

To finish off with my contribution, I initially bewailed the loss of
some functionalities that straightly threatened some home-made pieces of
code I use daily and intensively.
I rencently worked for a customer who needed to upgrade a series a
ArcInfo AML routines I wrote for him some years ago for AI7.2 and which
did not work properly now on AI9. I praised him that developing his
future personalized solutions on GRASS would be a guarantee of
long-lasting, reliabilty, and so on... oops !

Vincent

[Hamish]

Markus wrote:

I type in bash CTRL-R and a fraction of what I remember of
the name, then maybe another few CTRL-R to cycle to the right
one. Enter and I see it.

fwiw I find ^r a bit confusing to use. (user ignorance of the sublties
I'm sure..)

I much prefer to use PgUp/PgDn after typing the partial command,

create a file called ~/.inputrc containing:
################################
set prefer-visible-bell

# -------- Bind page up/down wih history search ---------
"\e[5~": history-search-backward
"\e[6~": history-search-forward
################################

I got really used to this in the matlab console (up/down arrow there)
and it hurt not to have it in bash until I learned the above trick.

for my 2c I think it's ultimately a losing battle to try and reimplement
bash ("poorly", to quote the famous phrase) and we should ship a minimal
wx based ximgview/qiv/display app with auto refesh on file update and
minimal g.region/d.zoom/d.where (right click menu only, strictly k.i.s.s.
like d.mon). I doubt it would take much effort to write or maintain as
long as we don't try to make it much more than a window into the data.
then hardcore folks can use csh/bash/emacs/whatever as they like without
the overhead of a gui.

it's too much to ask users to find a download an image viewer of their
own, especially when it's probably less than a few hundred lines of code
to ship our own wx based version.

for one thing I'd consider running that tunneled over ssh+X to a remote
number cruncher, but not a real GUI. a while ago while traveling and
only a borrowed win2k + puTTY to work with I rigged up a system where
the png driver wrote the display image across to a apache public dir
which I could reload in the web browser. not ideal, but it worked.

Hamish

[Jan_Hartmann]

I very much agree with Markus. The main point is that a command line interface is much faster than a GUI, once you have learned to use it. This can take a long time to learn (take the VIM editor for example), and for most people that is simply not worth it. When you “have it in your fingers” however, it really is much more efficient. I still use Grass54 for digitizing, even if I have to convert the vector maps into the new format, because digitizing, the most labour-intensive job there is in GIS, gets done much more efficiently with the left hand using the keyboard, and the right hand using the mouse. That program has disappeared, but Markus’s example illustrates perfectly the case for the actual version of GRASS.

I understand that programmers have limited time and resources, and I certainly agree that these should be spent on the GUI: it’s important for many more people than the bunch of old-hand command line hackers. I would plead however to leave as much of the old functionality in place as possible. If I understand Glynn’s posting on this subject correctly however, this will be very difficult, as the Vask library has been removed (why?), and all mouse interaction has been dropped from the display commands.

If that is too much trouble, I would be perfectly happy to use older versions of GRASS for dedicated purposes, provided I could use the same mapsets. Copying and converting maps between different versions if the program is a major source of errors, some of them very insidious. Would that be an alternative for retaining old functionality: reading directly from old-style databases?

Jan

Markus Neteler wrote:

[Hamish]

Vincent wrote:

I praised him that developing his
future personalized solutions on GRASS would be a guarantee
of long-lasting, reliabilty, and so on... oops !

backwards compatibility since grass 6.0.0 in March 2005 is no mistake.
it suggests that any code written for grass 7 will work for a similar time
frame. and there is nothing stopping anyone from running grass 6.x well
into the future, or continue with grass 5.4 for that matter.

to limit ourselves from any change would guarantee obsolescence. the
great trick is to compress all that good change into a single instant
which are far appart, rather than to allow continual change with no
stability.

regards,
Hamish

[Vincent_Bain]

Hamish,
you're right, anyone can still freely use former but stable versions of
Grass (like Jan does with grass5 for digitizing) for his particular
purposes.
Looking towards future I just figure out it's high time I began learning
python

Anyway, thank you all for this interesting discussion,

Vincent.

Le samedi 05 décembre 2009 à 02:51 -0800, Hamish a écrit :

Vincent wrote:
> I praised him that developing his
> future personalized solutions on GRASS would be a guarantee
> of long-lasting, reliabilty, and so on... oops !

backwards compatibility since grass 6.0.0 in March 2005 is no mistake.
it suggests that any code written for grass 7 will work for a similar time
frame. and there is nothing stopping anyone from running grass 6.x well
into the future, or continue with grass 5.4 for that matter.

to limit ourselves from any change would guarantee obsolescence. the
great trick is to compress all that good change into a single instant
which are far appart, rather than to allow continual change with no
stability.

regards,
Hamish

[cmbarton]

GRASS is very cautious with regards to upgrades--some would say too cautious. Great care is taken to maintain all backward compatibility within a version. That is, code written for version 6.0 should run on version 6.4rc5.

However, the program needs to evolve too. This happens between major version numbers. For example, the vector file structure changed dramatically between version 5 and 6--for the better AFAIC because it made for the default link between vector objects and attribute tables. But this still will break some scripts.

Between 6 and 7 there will be changes to the raster file structure. Also, the display architecture is being cleaned up a lot. A great many GRASS modules called in scripts dating from version 4 will still run in version 7. You can translate files created in version 4 to version 7. One of the changes in 7 is to get rid of an old interactive mode that affected a subset of the d* modules. This mode has restricted GRASS to a tiny fraction of the computers used by people today. I'm a die-hard Mac user and I like Linux, but I realize that even together, these constitute a small proportion of the OS used by people across the world. Even for me, running d.mon and d.rast was handy, but this is easily replaced. The interactive parts of d.measure, d.zoom, etc have been replaced by an alternate way of interacting with a mouse. Scripts which depended on these for interaction were depending on an interaction mode and display architecture dating to the 1980's. In "computer years", that must be at least a century or two It's amazing that GRASS has maintained that architecture so long, but it has done so at increasing cost for functionality and access by users. The changes in architecture with version 7 have been discussed on the dev list and in the WIKI for over two years.

The point is that to me at least this seems like a LOT of stability for computer software. Recently, I discovered some files that I had forgotten to upgrade from Microsoft Word ver. 3 in the early 1990's. So far, I have not been able to find anything to read these files. A GRASS file from that era can be read and many scripts written in that era will still run. Most of those that won't run can be made to do so with minimal tweaking. At the same time, GRASS has been modified to also work with a wider variety of scripting languages, with a special emphasis on Python--an easy to use open source language widely used in the sciences. So IMHO your advice to the client is not at all off the mark.

Michael

On Dec 5, 2009, at 2:11 AM, Vincent Bain wrote:

Le vendredi 04 décembre 2009 à 14:16 -0700, Michael Barton a écrit :

Markus,

This is helpful. Much more so than simply those that ask 'why can't we
do things the way we did'.

Michael,

as far as I am concerned by your remark, I just wish to distinguish my
attitude from that of a potential pure fastidious/demanding consumer : I
just keep very cautious from giving "advices" when I feel like being a
too modest contributor...

To finish off with my contribution, I initially bewailed the loss of
some functionalities that straightly threatened some home-made pieces of
code I use daily and intensively.
I rencently worked for a customer who needed to upgrade a series a
ArcInfo AML routines I wrote for him some years ago for AI7.2 and which
did not work properly now on AI9. I praised him that developing his
future personalized solutions on GRASS would be a guarantee of
long-lasting, reliabilty, and so on... oops !

Vincent

[Vincent_Bain]

Thank you Michael and others, I really appreciate the time you allow to
clarify these points. I am convinced the discussion will have been
benefic to many other users.

Yours,
Vincent.

[cmbarton]

On Dec 5, 2009, at 2:27 AM, Hamish wrote:

Markus wrote:

I type in bash CTRL-R and a fraction of what I remember of
the name, then maybe another few CTRL-R to cycle to the right
one. Enter and I see it.

fwiw I find ^r a bit confusing to use. (user ignorance of the sublties
I'm sure..)

I much prefer to use PgUp/PgDn after typing the partial command,

create a file called ~/.inputrc containing:
################################
set prefer-visible-bell

# -------- Bind page up/down wih history search ---------
"\e[5~": history-search-backward
"\e[6~": history-search-forward
################################

I got really used to this in the matlab console (up/down arrow there)
and it hurt not to have it in bash until I learned the above trick.

for my 2c I think it's ultimately a losing battle to try and reimplement
bash ("poorly", to quote the famous phrase) and we should ship a minimal
wx based ximgview/qiv/display app with auto refesh on file update and
minimal g.region/d.zoom/d.where (right click menu only, strictly k.i.s.s.
like d.mon). I doubt it would take much effort to write or maintain as
long as we don't try to make it much more than a window into the data.
then hardcore folks can use csh/bash/emacs/whatever as they like without
the overhead of a gui.

This is not understanding what is involved to do this. It IS a considerable effort to write and maintain a second interactive display that is a retro mimic of an old xmon.

It is is probably not a considerable effort to write and maintain a script that wraps display commands with an image viewer with automatic refresh. Keep in mind that the syntax would not be d.rast ... But it would still be a command line display. This is not a GUI. That's why it is doable with minimal effort.

The difficulty is creating a display that IS another GUI--that is a display interface that allows the user to use a mouse to control the display and other module functions like changing the region. Having written two of these, I have some idea of what is involved. Doing the menus for the 300+ commands is trivial. Creating a mouse-driven zoom box that changes the display to zoom in or out of a map is a lot of work and code. I'm afraid that I don't have the time or inclination to create and maintain a separate retro GUI for a few users, no matter how much I love you all. And I still can't understand why yet another mouse-operated GUI is needed.

Also, none of the comments I've yet seen on the list suggests that anyone has actually tried the command line interface that Martin and I DID build into the wxPython GUI at the request of the dev crowd. It is not an attempt to reimplement bash, but to offer an alternate way to interact with GRASS by typing commands. This DOES leverage the display and mouse-interaction code we have already built and maintain. You can type d.* commands and have maps displayed. You can then interact with the displayed maps with a mouse to zoom, measure, and query. Since you are going to use a mouse anyway, it is faster to click one button on the display you are already working with than to type "d.measure" from the keyboard. It is considerably easier to create and maintain a way to type commands from within the existing GUI than it is to create a 2nd GUI. However this CLI can't be improved without input.

Michael

it's too much to ask users to find a download an image viewer of their
own, especially when it's probably less than a few hundred lines of code
to ship our own wx based version.

for one thing I'd consider running that tunneled over ssh+X to a remote
number cruncher, but not a real GUI. a while ago while traveling and
only a borrowed win2k + puTTY to work with I rigged up a system where
the png driver wrote the display image across to a apache public dir
which I could reload in the web browser. not ideal, but it worked.

Hamish

[neteler]

On Sat, Dec 5, 2009 at 10:27 AM, Hamish <hamish_b@yahoo.com> wrote:

Markus wrote:

I type in bash CTRL-R and a fraction of what I remember of
the name, then maybe another few CTRL-R to cycle to the right
one. Enter and I see it.

fwiw I find ^r a bit confusing to use. (user ignorance of the sublties
I'm sure..)

I am working on many different remote systems, so I try to learn
the necessary minimum rather than focusing on a personal
optimization (sure I agree that that is handy if you work on
your only one or a few machines).

...

for one thing I'd consider running that tunneled over ssh+X to a remote
number cruncher, but not a real GUI. a while ago while traveling and
only a borrowed win2k + puTTY to work with I rigged up a system where
the png driver wrote the display image across to a apache public dir
which I could reload in the web browser. not ideal, but it worked.

Right, working over ssh in GRASS is very common for me (70% of
overall time, often even over unstable connections). So I learned to
love "screen" to not crash the GRASS session. The d.* approach
consumes little resources only, that's why I like it so much...

Will later comment more on a previous mail of Michael.

Markus

[cmbarton]

I very much agree with Markus. The main point is that a command line interface is much faster than a GUI, once you have learned to use it. This can take a long time to learn (take the VIM editor for example), and for most people that is simply not worth it. When you “have it in your fingers” however, it really is much more efficient. I still use Grass54 for digitizing, even if I have to convert the vector maps into the new format, because digitizing, the most labour-intensive job there is in GIS, gets done much more efficiently with the left hand using the keyboard, and the right hand using the mouse. That program has disappeared, but Markus’s example illustrates perfectly the case for the actual version of GRASS.

A point on digitizing. If you haven’t tried it, you should take a look at the digitizing that Martin has built into the new GUI. Because it has hot-key equivalents for all buttons, you CAN digitize with your right hand on the mouse and left on the keyboard. It also has a lot of contextual menus that you access by right clicking while you digitize rather than having to move to a separate text area like in 5.4.

I understand that programmers have limited time and resources, and I certainly agree that these should be spent on the GUI: it’s important for many more people than the bunch of old-hand command line hackers. I would plead however to leave as much of the old functionality in place as possible. If I understand Glynn’s posting on this subject correctly however, this will be very difficult, as the Vask library has been removed (why?), and all mouse interaction has been dropped from the display commands.

Glynn has done a good job of describing why these libraries have been removed from a programming perspective. I just want to note that in GRASS 7, if you want to do GRASS completely via commands (i.e., that is NON-interactive), you can do so. Type commands from a system terminal or from the terminal built into the GUI. If you want to do GRASS completely interactively without typing commands, you can do so using the pulldowns, scrolling lists, buttons, etc of the wxPython GUI. If you want to type commands for all non-interactive uses of GRASS but want to interact with displayed maps using a mouse, you can do so in the GUI.

So far, the only concrete function that I’ve yet read that is missing from these varied ways to interact with GRASS is a command-line autocompletion that Markus mentioned. There may be other missing functionality but no one has detailed any.

If that is too much trouble, I would be perfectly happy to use older versions of GRASS for dedicated purposes, provided I could use the same mapsets. Copying and converting maps between different versions if the program is a major source of errors, some of them very insidious. Would that be an alternative for retaining old functionality: reading directly from old-style databases?

This is not something I do any coding for, but AFAIK, GRASS will continue to be able to read GRASS files from the past, either directly or via translation.

Michael

[cmbarton]

I actually do appreciate the input. I would like to make GRASS highly usable for as broad an audience as possible--from mouse junkies to command-line geeks. But this needs to also face pragmatic realities of available time and effort of the volunteers that do the coding. How can we get the most bang for the volunteer buck?

Michael

On Dec 5, 2009, at 8:28 AM, Vincent Bain wrote:

Thank you Michael and others, I really appreciate the time you allow to
clarify these points. I am convinced the discussion will have been
benefic to many other users.

Yours,
Vincent.

[cmbarton]

On Dec 5, 2009, at 8:48 AM, Markus Neteler wrote:

On Sat, Dec 5, 2009 at 10:27 AM, Hamish <hamish_b@yahoo.com> wrote:

Markus wrote:

I type in bash CTRL-R and a fraction of what I remember of
the name, then maybe another few CTRL-R to cycle to the right
one. Enter and I see it.

fwiw I find ^r a bit confusing to use. (user ignorance of the sublties
I'm sure..)

I am working on many different remote systems, so I try to learn
the necessary minimum rather than focusing on a personal
optimization (sure I agree that that is handy if you work on
your only one or a few machines).

...

for one thing I'd consider running that tunneled over ssh+X to a remote
number cruncher, but not a real GUI. a while ago while traveling and
only a borrowed win2k + puTTY to work with I rigged up a system where
the png driver wrote the display image across to a apache public dir
which I could reload in the web browser. not ideal, but it worked.

Right, working over ssh in GRASS is very common for me (70% of
overall time, often even over unstable connections). So I learned to
love "screen" to not crash the GRASS session. The d.* approach
consumes little resources only, that's why I like it so much...

Can the d.* rendered to a small footprint image viewer work in this setting?

Michael

Will later comment more on a previous mail of Michael.

Markus

[cmbarton]

So here is an idea for a lightweight GRASS CLI to run from a system terminal

1) a Python script that will set the display variables and launch an image viewer with autorefresh as Glynn has mentioned. It would use the Python "input" function to allow for the user to type multiple d.rast and d.vect commands.

2) a script named g.zoom. This script runs g.region and will reset the computational (and display) region by a positive or negative percentage around the center point or optionally around a point whose coordinates the user inputs

3) a script named g.pan. This script runs g.region to shift the computational (and display) region by a percent or by a unit value in some cardinal direction

Michael

[Jan_Hartmann]

Michael Barton wrote:

A point on digitizing. If you haven't tried it, you should take a look at the digitizing that Martin has built into the new GUI. Because it has hot-key equivalents for all buttons, you CAN digitize with your right hand on the mouse and left on the keyboard. It also has a lot of contextual menus that you access by right clicking while you digitize rather than having to move to a separate text area like in 5.4.

Ah, I hadn't realized that. Is that in GRASS 7? I don't use GRASS enough to compile the unstable versions, but now it's the first thing I am going to do on Monday. Takes away my only major problem with GRASS.
BTW, I see that I asked for this last February (http://lists.osgeo.org/pipermail/grass-user/2009-February/048986.html). Don't know if that was the reason for the hot-keys, but thanks anyway.

If that is too much trouble, I would be perfectly happy to use older versions of GRASS for dedicated purposes, provided I could use the same mapsets. Copying and converting maps between different versions if the program is a major source of errors, some of them very insidious. Would that be an alternative for retaining old functionality: reading directly from old-style databases?

This is not something I do any coding for, but AFAIK, GRASS will continue to be able to read GRASS files from the past, either directly or via translation.

It's not that important for me any more now, but perhaps older versions of GRASS could be bundled as Qgis in OsGeo4W, where you can install one or more of four versions. For Linux, you could think of distributing them like the FWTools utilities: each version in a single directory tree, including all the dependencies (and even a complete Python). That way, different versions can be used without conflicts between library versions. At least, that is the way I manage them on the cluster I am working on, to get quick functional copies on different nodes.

Jan

[martinl]

Hi,

2009/12/5 Jan Hartmann <j.l.h.hartmann@uva.nl>:

A point on digitizing. If you haven't tried it, you should take a look at
the digitizing that Martin has built into the new GUI. Because it has
hot-key equivalents for all buttons, you CAN digitize with your right hand
on the mouse and left on the keyboard. It also has a lot of contextual menus
that you access by right clicking while you digitize rather than having to
move to a separate text area like in 5.4.

Ah, I hadn't realized that. Is that in GRASS 7? I don't use GRASS enough

no, it waits to be implemented (generally speaking easy task), see [1].

Martin

[1] http://trac.osgeo.org/grass/ticket/497

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[Dylan_Beaudette]

On Saturday 05 December 2009, Markus Neteler wrote:

On Sat, Dec 5, 2009 at 10:27 AM, Hamish <hamish_b@yahoo.com> wrote:
> Markus wrote:
>> I type in bash CTRL-R and a fraction of what I remember of
>> the name, then maybe another few CTRL-R to cycle to the right
>> one. Enter and I see it.
>
> fwiw I find ^r a bit confusing to use. (user ignorance of the sublties
> I'm sure..)

I am working on many different remote systems, so I try to learn
the necessary minimum rather than focusing on a personal
optimization (sure I agree that that is handy if you work on
your only one or a few machines).

...

> for one thing I'd consider running that tunneled over ssh+X to a remote
> number cruncher, but not a real GUI. a while ago while traveling and
> only a borrowed win2k + puTTY to work with I rigged up a system where
> the png driver wrote the display image across to a apache public dir
> which I could reload in the web browser. not ideal, but it worked.

Right, working over ssh in GRASS is very common for me (70% of
overall time, often even over unstable connections). So I learned to
love "screen" to not crash the GRASS session. The d.* approach
consumes little resources only, that's why I like it so much...

Hi,

I would just like to mention that several GRASS users in our research group
use GRASS in this way. The ability to check on remote jobs via d.* commands
is critical to the way we use GRASS. I am not insisting that we preserve
them, however, it would be nice to have similar functionality in GRASS 7.
Loading the current GUI over a slow SSH connection is not really an ideal
solution.

So far it sounds like a wrapper than sets environmental variables is a good
start. I suppose that would work, with some kind of auto-refresh png viewer.

Is it possible to use the Wx canvas (without all of the other GUI stuff) such
that it can be written to with d.* commands?

Cheers,
Dylan

Will later comment more on a previous mail of Michael.

Markus
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

[cmbarton]

On Dec 7, 2009, at 10:29 AM, Dylan Beaudette wrote:

On Saturday 05 December 2009, Markus Neteler wrote:

On Sat, Dec 5, 2009 at 10:27 AM, Hamish <hamish_b@yahoo.com> wrote:

Markus wrote:

I type in bash CTRL-R and a fraction of what I remember of
the name, then maybe another few CTRL-R to cycle to the right
one. Enter and I see it.

fwiw I find ^r a bit confusing to use. (user ignorance of the sublties
I'm sure..)

I am working on many different remote systems, so I try to learn
the necessary minimum rather than focusing on a personal
optimization (sure I agree that that is handy if you work on
your only one or a few machines).

...

for one thing I'd consider running that tunneled over ssh+X to a remote
number cruncher, but not a real GUI. a while ago while traveling and
only a borrowed win2k + puTTY to work with I rigged up a system where
the png driver wrote the display image across to a apache public dir
which I could reload in the web browser. not ideal, but it worked.

Right, working over ssh in GRASS is very common for me (70% of
overall time, often even over unstable connections). So I learned to
love "screen" to not crash the GRASS session. The d.* approach
consumes little resources only, that's why I like it so much...

Hi,

I would just like to mention that several GRASS users in our research group
use GRASS in this way. The ability to check on remote jobs via d.* commands
is critical to the way we use GRASS. I am not insisting that we preserve
them, however, it would be nice to have similar functionality in GRASS 7.
Loading the current GUI over a slow SSH connection is not really an ideal
solution.

So far it sounds like a wrapper than sets environmental variables is a good
start. I suppose that would work, with some kind of auto-refresh png viewer.

Is it possible to use the Wx canvas (without all of the other GUI stuff) such
that it can be written to with d.* commands?

Not in a way that would help you in this situation. The canvas is tightly integrated into the GUI as written and in fact canvas and related code accounts for much of the size of the GUI. You could code a different canvas of course, but it would still have to load Python and wxPython (or TkInter) to run. Keep in mind that the first time this is run, it compiles binary versions of all files. All subsequent loads are much faster and smaller.

If you can't use the canvas built into the GUI, it would seem easier to use something already out there instead of taking the effort to code another canvas from scratch and then maintain it across evolving GRASS, Python, and wxPython versions.

I suspect that the main reason that the old d.mon type displays seemed smaller is that they leveraged the graphic code built into XWindows. This won't work on Windows (without an emulator that of course slows things down a lot) and most Mac users don't use XWindows. Which ever way you slice it, something has to do the job of rendering and displaying in a windowed environment. For interaction, you also need to add something that can sense different kinds of mouse events, decide if they are in a relevant window or not, capture their coordinates within the window, get the window size in pixels, sense if the window geometry has change, do the math to translate from xy pixel locations to projected and unprojected geographic coordinate and back, draw to the window, send information back to grass to change its region, have grass re-display maps to the graphic files, composite the files into a single image, and re-render the image.

Michael

Cheers,
Dylan

Will later comment more on a previous mail of Michael.

Markus
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341