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 <[email protected]> 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
[email protected]
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
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
