[GRASS-user] grass70 and display monitor

[Michael Barton]

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 at 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