<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"> </div><br><div><div>On Dec 5, 2009, at 3:14 AM, Jan Hartmann wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"> <div bgcolor="#ffffff" text="#000000"> 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.<br></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"> <br> 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. <br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"> <br> 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?<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Michael</div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"> <br> Jan<br> <br> Markus Neteler wrote: <blockquote cite="mid:86782b610912041244o28510163pe20969dcde4e4fb6@mail.gmail.com" type="cite"> <pre wrap="">On Fri, Dec 4, 2009 at 3:23 PM, Michael Barton <a class="moz-txt-link-rfc2396E" href="mailto:michael.barton@asu.edu"><michael.barton@asu.edu></a> wrote:
</pre> <blockquote type="cite"> <pre wrap="">Roy,
I guess you haven't been following quite all of this discussion.
</pre> </blockquote> <pre wrap=""><!---->
Sincerely, I am in the same boat apparently, see below.
</pre> <blockquote type="cite"> <pre wrap="">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.
</pre> </blockquote> <pre wrap=""><!---->
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.
</pre> <blockquote type="cite"> <pre wrap="">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.
</pre> </blockquote> <pre wrap=""><!---->
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 :)
</pre> <blockquote type="cite"> <pre wrap="">Besides simply not being GRASS 4 or 5 (which are still available to be run),
what functionality are you missing?
</pre> </blockquote> <pre wrap=""><!---->
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
_______________________________________________
grass-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/grass-user">http://lists.osgeo.org/mailman/listinfo/grass-user</a>
</pre> </blockquote> </div> </blockquote></div><br></body></html>