[GRASS-user] grass70 and display monitor

[Michael Barton]

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