Re: [GRASS-user] grass70 and display monitor
There is no use of xmonitors in GRASS 7. There is a recent and ongoing discussion of alternatives on the Dev list. Look for the "Shell scripts" thread. Michael C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 2, 2009, at 10:34 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Wed, 02 Dec 2009 18:22:15 +0100 From: Vincent Bain Subject: [GRASS-user] grass70 and display monitor To: GRASS user list Message-ID: <1259774535.11312.12.ca...@vincent-desktop> Content-Type: text/plain Dear grass users, my question could be insane but I am wondering if there is an equivalent command to d.mon in grass70. In several man pages I saw a reference to d.frame but it seems not be implemented yet. Or will grass70 give up with x monitors ? considering one still can launch grass in text mode, I guess there might be a way to open a graphical device. thank you for your commentaries on this question, Vincent. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Thank you Michael, I found the thread... Yours, Vincent Le mercredi 02 décembre 2009 à 10:37 -0700, Michael Barton a écrit : > There is no use of xmonitors in GRASS 7. There is a recent and ongoing > discussion of alternatives on the Dev list. Look for the "Shell > scripts" thread. > > Michael > > C. Michael Barton > Director, Center for Social Dynamics & Complexity > Professor of Anthropology, School of Human Evolution & Social Change > Arizona State University > > Phone: 480-965-6262 > Fax: 480-965-7671 > www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu > > > > > > > > On Dec 2, 2009, at 10:34 AM, grass-user-requ...@lists.osgeo.org wrote: > > > Date: Wed, 02 Dec 2009 18:22:15 +0100 > > From: Vincent Bain > > Subject: [GRASS-user] grass70 and display monitor > > To: GRASS user list > > Message-ID: <1259774535.11312.12.ca...@vincent-desktop> > > Content-Type: text/plain > > > > Dear grass users, > > > > my question could be insane but I am wondering if there is an > > equivalent > > command to d.mon in grass70. > > In several man pages I saw a reference to d.frame but it seems not be > > implemented yet. > > > > Or will grass70 give up with x monitors ? considering one still can > > launch grass in text mode, I guess there might be a way to open a > > graphical device. > > > > thank you for your commentaries on this question, > > > > Vincent. > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
And for easy reference, here is the thread: http://lists.osgeo.org/pipermail/grass-dev/2009-November/047135.html Cheers, John On Dec 2, 2009, at 9:46 AM, Vincent Bain wrote: > Thank you Michael, I found the thread... > > Yours, > Vincent > > > > Le mercredi 02 décembre 2009 à 10:37 -0700, Michael Barton a écrit : >> There is no use of xmonitors in GRASS 7. There is a recent and ongoing >> discussion of alternatives on the Dev list. Look for the "Shell >> scripts" thread. >> >> Michael >> >> C. Michael Barton >> Director, Center for Social Dynamics & Complexity >> Professor of Anthropology, School of Human Evolution & Social Change >> Arizona State University >> >> Phone: 480-965-6262 >> Fax: 480-965-7671 >> www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu >> >> >> >> >> >> >> >> On Dec 2, 2009, at 10:34 AM, grass-user-requ...@lists.osgeo.org wrote: >> >>> Date: Wed, 02 Dec 2009 18:22:15 +0100 >>> From: Vincent Bain >>> Subject: [GRASS-user] grass70 and display monitor >>> To: GRASS user list >>> Message-ID: <1259774535.11312.12.ca...@vincent-desktop> >>> Content-Type: text/plain >>> >>> Dear grass users, >>> >>> my question could be insane but I am wondering if there is an >>> equivalent >>> command to d.mon in grass70. >>> In several man pages I saw a reference to d.frame but it seems not be >>> implemented yet. >>> >>> Or will grass70 give up with x monitors ? considering one still can >>> launch grass in text mode, I guess there might be a way to open a >>> graphical device. >>> >>> thank you for your commentaries on this question, >>> >>> Vincent. >> >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Vincent Bain wrote: > my question could be insane but I am wondering if there is an equivalent > command to d.mon in grass70. > In several man pages I saw a reference to d.frame but it seems not be > implemented yet. > > Or will grass70 give up with x monitors ? considering one still can > launch grass in text mode, I guess there might be a way to open a > graphical device. GRASS 7.0 does not support monitors. The various display "drivers" are libraries against which the display library is linked. There are no persistent monitor processes as in 6.x, meaning that there is no persistence of state between d.* commands, so no d.frame, d.font etc. All rendering parameters are set via environment variables. Some of these are listed in the "variables" manual page, while others are listed in the manual pages for the various drivers. You can approximate the pre-7.0 workflow using an image viewer which automatically refreshes the display whenever the file changes. For X, you can use the ximgview program, e.g.: export GRASS_PNGFILE=map.bmp d.erase ximgview & export GRASS_PNG_MAPPED=TRUE export GRASS_PNG_READ=TRUE # more d.* commands -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Thank you for your answers and advices. Glynn, with your method based on displaying grass files on the fly in a viewer, I guess all d.* interactive commands will fail, won't they ? Deep down I want to know how much I will have to adapt some shell scripts I wrote for grass6* when my users migrate to grass70. My feeling on this point with care for durability of the application - and I think grass is mostly used by people in search of customization - is it would be nice that be maintained these fundamentals... To my mind it is one of the most important benefits of open source apps. On the other hand I am not aware enough of the constraints that lead to drop x monitors. Bye, Vincent Le jeudi 03 décembre 2009 à 06:00 +, Glynn Clements a écrit : > Vincent Bain wrote: > > > my question could be insane but I am wondering if there is an equivalent > > command to d.mon in grass70. > > In several man pages I saw a reference to d.frame but it seems not be > > implemented yet. > > > > Or will grass70 give up with x monitors ? considering one still can > > launch grass in text mode, I guess there might be a way to open a > > graphical device. > > GRASS 7.0 does not support monitors. The various display "drivers" are > libraries against which the display library is linked. There are no > persistent monitor processes as in 6.x, meaning that there is no > persistence of state between d.* commands, so no d.frame, d.font etc. > > All rendering parameters are set via environment variables. Some of > these are listed in the "variables" manual page, while others are > listed in the manual pages for the various drivers. > > You can approximate the pre-7.0 workflow using an image viewer which > automatically refreshes the display whenever the file changes. For X, > you can use the ximgview program, e.g.: > > export GRASS_PNGFILE=map.bmp > d.erase > ximgview & > export GRASS_PNG_MAPPED=TRUE > export GRASS_PNG_READ=TRUE > # more d.* commands > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Hi John and others, (and for easy reference as well to whom it may concern) I think the discussion that best corresponds to my question is here : http://lists.osgeo.org/pipermail/grass-dev/2009-August/045399.html Vincent. Le mercredi 02 décembre 2009 à 10:47 -0800, John C. Tull a écrit : > And for easy reference, here is the thread: > > http://lists.osgeo.org/pipermail/grass-dev/2009-November/047135.html > > Cheers, > John > > On Dec 2, 2009, at 9:46 AM, Vincent Bain wrote: > > > Thank you Michael, I found the thread... > > > > Yours, > > Vincent > > > > > > > > Le mercredi 02 décembre 2009 à 10:37 -0700, Michael Barton a écrit : > >> There is no use of xmonitors in GRASS 7. There is a recent and ongoing > >> discussion of alternatives on the Dev list. Look for the "Shell > >> scripts" thread. > >> > >> Michael > >> > >> C. Michael Barton > >> Director, Center for Social Dynamics & Complexity > >> Professor of Anthropology, School of Human Evolution & Social Change > >> Arizona State University > >> > >> Phone: 480-965-6262 > >> Fax: 480-965-7671 > >> www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu > >> > >> > >> > >> > >> > >> > >> > >> On Dec 2, 2009, at 10:34 AM, grass-user-requ...@lists.osgeo.org wrote: > >> > >>> Date: Wed, 02 Dec 2009 18:22:15 +0100 > >>> From: Vincent Bain > >>> Subject: [GRASS-user] grass70 and display monitor > >>> To: GRASS user list > >>> Message-ID: <1259774535.11312.12.ca...@vincent-desktop> > >>> Content-Type: text/plain > >>> > >>> Dear grass users, > >>> > >>> my question could be insane but I am wondering if there is an > >>> equivalent > >>> command to d.mon in grass70. > >>> In several man pages I saw a reference to d.frame but it seems not be > >>> implemented yet. > >>> > >>> Or will grass70 give up with x monitors ? considering one still can > >>> launch grass in text mode, I guess there might be a way to open a > >>> graphical device. > >>> > >>> thank you for your commentaries on this question, > >>> > >>> Vincent. > >> > >> ___ > >> grass-user mailing list > >> grass-user@lists.osgeo.org > >> http://lists.osgeo.org/mailman/listinfo/grass-user > >> > > > > ___ > > grass-user mailing list > > grass-user@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/grass-user > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Vincent Bain wrote: > Glynn, with your method based on displaying grass files on the fly in a > viewer, I guess all d.* interactive commands will fail, won't they ? There are no interactive d.* commands in 7.0. The 7.0 display architecture doesn't have any facility to query a mouse. Any modules which depended upon such functionality have either been removed entirely or have had the corresponding functionality removed. > Deep down I want to know how much I will have to adapt some shell > scripts I wrote for grass6* when my users migrate to grass70. > > My feeling on this point with care for durability of the application - > and I think grass is mostly used by people in search of customization - > is it would be nice that be maintained these fundamentals... To my mind > it is one of the most important benefits of open source apps. This isn't going to change. If you want interaction, you need to either extend the GUI, or leverage existing functionality (e.g. by using the digitiser to create a vector map or the georectifier to create GCPs, then using this data as input). > On the other hand I am not aware enough of the constraints that lead > to drop x monitors. The interactive features made it impractical to build a decent GUI on top of the display commands. Additionally, the monitor-based architecture meant that it took an excessive amount of work to implement relatively minor improvements, as well as making debugging difficult. Oh, and none of it worked on Windows. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Thanks for your reply, May I be considered bothersome, but was it really impossible to achieve (like in grass65) the development of a wxGUI (which I really enjoy too) while keeping the complete set of "historical" command line environment ? Le jeudi 03 décembre 2009 à 14:40 +, Glynn Clements a écrit : > Vincent Bain wrote: > > > Glynn, with your method based on displaying grass files on the fly in a > > viewer, I guess all d.* interactive commands will fail, won't they ? > > There are no interactive d.* commands in 7.0. > > The 7.0 display architecture doesn't have any facility to query a > mouse. Any modules which depended upon such functionality have either > been removed entirely or have had the corresponding functionality > removed. > > > Deep down I want to know how much I will have to adapt some shell > > scripts I wrote for grass6* when my users migrate to grass70. > > > > My feeling on this point with care for durability of the application - > > and I think grass is mostly used by people in search of customization - > > is it would be nice that be maintained these fundamentals... To my mind > > it is one of the most important benefits of open source apps. > > This isn't going to change. If you want interaction, you need to > either extend the GUI, or leverage existing functionality (e.g. by > using the digitiser to create a vector map or the georectifier to > create GCPs, then using this data as input). > > > On the other hand I am not aware enough of the constraints that lead > > to drop x monitors. > > The interactive features made it impractical to build a decent GUI on > top of the display commands. Additionally, the monitor-based > architecture meant that it took an excessive amount of work to > implement relatively minor improvements, as well as making debugging > difficult. Oh, and none of it worked on Windows. > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Vincent Bain wrote: > May I be considered bothersome, but was it really impossible to achieve > (like in grass65) the development of a wxGUI (which I really enjoy too) > while keeping the complete set of "historical" command line > environment ? Very little is actually impossible, but the disadvantages (in terms of both effort and detriment to the end product) far outweigh the advantages. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
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.sander...@newcastle.ac.uk 0191 246 4835 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Roy Sanderson wrote: > 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. Most of the d.* commands, including d.rast and d.vect, aren't going anywhere. The only change is that d.* commands now only support immediate rendering (i.e. generating image files directly). Much of what works in 6.x still works in 7.0. With regard to the display architecture, the main differences are that: 1. Communication between d.* modules and the display architecture is one-way. d.* modules tell the libraries to draw stuff and they draw it. The mouse functions (wait for the user to press a mouse button and report the coordinates) no longer exist, so any modules which depend upon them have been removed, re-written, assimilated into the GUI, or remain minus the mouse interaction (e.g. d.legend, d.barscale etc still exist but lack the ability to use the mouse for placement). 2. There are no persistent monitor processes, so there are no commands to start and stop monitors (d.mon), or to change the monitor state for future commands (d.frame, d.font) or to read the current state (d.save). Any parameters (font, encoding, text size, line width, frame coordinates, etc) are passed via environment variables. It would be fairly trivial to use $GISRC variables instead, if there was any demand for it, although setting environment variables is slightly simpler for the GUI. One thing which has disappeared and hasn't yet returned in any form is i.ortho.photo. Some people said that it was important, but no-one seems to have found it important enough to work on a replacement. And in a volunteer-run project, that's the only definition of "important" which really matters. The alternative (indefinitely retaining the awful messes which were the old graphics architecture and the vask library for the sake of i.ortho.photo) isn't realistic. Other than the display library, the vask library has been removed, along with anything which tries to ask the user questions via the terminal (e.g. G_ask_*). Assuming that there even *is* a terminal is now considered a bug. This bug used to manifest itself via the GUI hanging because it ran a command which then tried to interact with the user via stdin/stdout (even though stdin/stdout were probably either the ~/.xsession-errors file on Unix or non-existent on Windows and Mac). Similar issues affected batch jobs and web applications. Now, any such bugs would show up as undefined references to the non-existent G_ask_* functions. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
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-requ...@lists.osgeo.org wrote: Date: Fri, 04 Dec 2009 08:29:46 + From: Roy Sanderson Subject: Re: [GRASS-user] grass70 and display monitor To: gl...@gclements.plus.com Cc: grass-user@lists.osgeo.org Message-ID: <1259915386.16719.126.ca...@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.sander...@newcastle.ac.uk 0191 246 4835 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Fri, Dec 4, 2009 at 3:23 PM, Michael Barton 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
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 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 i
Re: [GRASS-user] grass70 and display monitor
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
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
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
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: On Fri, Dec 4, 2009 at 3:23 PM, Michael Barton 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
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 > > > > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
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. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
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
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Sat, Dec 5, 2009 at 10: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 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Dec 5, 2009, at 3:14 AM, Jan Hartmann wrote: 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 Jan Markus Neteler wrote: On Fri, Dec 4, 2009 at 3:23 PM, Michael Barton > 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 scr
Re: [GRASS-user] grass70 and display monitor
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. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Dec 5, 2009, at 8:48 AM, Markus Neteler wrote: On Sat, Dec 5, 2009 at 10: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 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Hi, 2009/12/5 Jan Hartmann : >> 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 * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Saturday 05 December 2009, Markus Neteler wrote: > On Sat, Dec 5, 2009 at 10: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 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
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 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Thu, 2009-12-03 at 18:59 +, Glynn Clements wrote: > Vincent Bain wrote: > > > May I be considered bothersome, but was it really impossible to achieve > > (like in grass65) the development of a wxGUI (which I really enjoy too) > > while keeping the complete set of "historical" command line > > environment ? > > Very little is actually impossible, but the disadvantages (in terms of > both effort and detriment to the end product) far outweigh the > advantages. I loved the "d.mon & co" tools ;-). But I understand that they had to be dropped. Is there already something in the wiki (with respect to grass70 and interactive d.* tools)? Thanks, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Sat, 2009-12-05 at 16:28 +0100, 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. Indeed it does. Comment: WoW!!! I was not following the lists the last weeks. It's been a super-discussion (about grass7 & d.mon's). Thanks, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Thanks. We'll keep working on it. Michael C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 17, 2009, at 4:32 PM, Νίκος Αλεξανδρής wrote: > On Sat, 2009-12-05 at 16:28 +0100, 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. > > Indeed it does. Comment: WoW!!! I was not following the lists the last > weeks. It's been a super-discussion (about grass7 & d.mon's). > > Thanks, Nikos > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Dec 18, 2009, at 3:45 AM, grass-user-requ...@lists.osgeo.org wrote: > Date: Thu, 17 Dec 2009 23:21:18 +0100 > From: ? ?? > Subject: Re: [GRASS-user] grass70 and display monitor > To: Glynn Clements > Cc: GRASS user list > Message-ID: <1261088478.7528.2.ca...@vertical> > Content-Type: text/plain; charset="UTF-8" > > On Thu, 2009-12-03 at 18:59 +, Glynn Clements wrote: >> Vincent Bain wrote: >> >>> May I be considered bothersome, but was it really impossible to achieve >>> (like in grass65) the development of a wxGUI (which I really enjoy too) >>> while keeping the complete set of "historical" command line >>> environment ? >> >> Very little is actually impossible, but the disadvantages (in terms of >> both effort and detriment to the end product) far outweigh the >> advantages. > > I loved the "d.mon & co" tools ;-). But I understand that they had to be > dropped. Is there already something in the wiki (with respect to grass70 > and interactive d.* tools)? > > Thanks, Nikos Nikos, Rather than trying to have primitive interaction built in to different display modules, they all now work as true command line tools where you type a command with arguments and get a result. All d.* modules that worked as command line tools before (e.g., d.rast, d.vect) still work that way. See further explanations at <http://lists.osgeo.org/pipermail/grass-user/2009-December/053520.html> For d.* modules that had some kind of primitive GUI built into the module, they have either been switched to true command-line tools or are dropped from GRASS 7 until they are rewritten to that standard. Instead of trying to build interaction into each module, they all can now work with an independent GUI layer on top of the modules. This is what it is for. The current GUI will do all of the interaction of prior d.* modules with built-in GUI with the exception of a few modules (notably r.digit [super primitive and not really needed with vdigit and v.to.rast], i.class, and i.ortho.photo) and more. So you can do what you did before in a nicer environment. Michael___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Nikos: >> May I be considered bothersome, but was it really impossible to >> achieve (like in grass65) the development of a wxGUI >> (which I really enjoy too) while keeping the complete set of >> "historical" command line environment ? Glynn: > Very little is actually impossible, but the disadvantages (in terms of > both effort and detriment to the end product) far outweigh the > advantages. Rest assured that when all the dust has settled from the new GUI work, if there remains demand for control from the (bash) command line, it will be provided in some form or another. this is free software after all and itches do get scratched. To echo Glynn, I can guarantee that the "complete set" of d.* will not survive, and that it is extremely unlikely that there will be any competing menu driven GUIs. I do expect that some purposefully simple PPM image monitor window will happen one day. Don't expect it to be very interactive or stateful, or even more than just an official addon. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
# Small correction (just for the records :-p) # Vincent: > >> May I be considered bothersome, but was it really impossible to > >> achieve (like in grass65) the development of a wxGUI > >> (which I really enjoy too) while keeping the complete set of > >> "historical" command line environment ? > Glynn: > > Very little is actually impossible, but the disadvantages (in terms of > > both effort and detriment to the end product) far outweigh the > > advantages. > Rest assured that when all the dust has settled from the new GUI work, > if there remains demand for control from the (bash) command line, it > will be provided in some form or another. this is free software after > all and itches do get scratched. > > To echo Glynn, I can guarantee that the "complete set" of d.* will not > survive, and that it is extremely unlikely that there will be any > competing menu driven GUIs. > > I do expect that some purposefully simple PPM image monitor window will > happen one day. Don't expect it to be very interactive or stateful, or > even more than just an official addon. > Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
On Fri, 2009-12-18 at 08:53 -0700, Michael Barton wrote: > > > On Dec 18, 2009, at 3:45 AM, grass-user-requ...@lists.osgeo.org wrote: > > > Date: Thu, 17 Dec 2009 23:21:18 +0100 > > From: ? ?????????? > > Subject: Re: [GRASS-user] grass70 and display monitor > > To: Glynn Clements > > Cc: GRASS user list > > Message-ID: <1261088478.7528.2.ca...@vertical> > > Content-Type: text/plain; charset="UTF-8" > > > > On Thu, 2009-12-03 at 18:59 +, Glynn Clements wrote: > >> Vincent Bain wrote: > >> > >>> May I be considered bothersome, but was it really impossible to achieve > >>> (like in grass65) the development of a wxGUI (which I really enjoy too) > >>> while keeping the complete set of "historical" command line > >>> environment ? > >> > >> Very little is actually impossible, but the disadvantages (in terms of > >> both effort and detriment to the end product) far outweigh the > >> advantages. > > > > I loved the "d.mon & co" tools ;-). But I understand that they had to be > > dropped. Is there already something in the wiki (with respect to grass70 > > and interactive d.* tools)? > > > > Thanks, Nikos > > Nikos, > > Rather than trying to have primitive interaction built in to different > display modules, they all now work as true command line tools where you type > a command with arguments and get a result. All d.* modules that worked as > command line tools before (e.g., d.rast, d.vect) still work that way. See > further explanations at > <http://lists.osgeo.org/pipermail/grass-user/2009-December/053520.html> > > For d.* modules that had some kind of primitive GUI built into the module, > they have either been switched to true command-line tools or are dropped from > GRASS 7 until they are rewritten to that standard. > > Instead of trying to build interaction into each module, they all can now > work with an independent GUI layer on top of the modules. This is what it is > for. The current GUI will do all of the interaction of prior d.* modules with > built-in GUI with the exception of a few modules (notably r.digit [super > primitive and not really needed with vdigit and v.to.rast], i.class, and > i.ortho.photo) and more. > > So you can do what you did before in a nicer environment. Michael, I did read (almost all of) your posts WRT to grass70 and d.*zzz. However, I want to say that, honestly, I appreciate the time you invest for clarifications (again). It's one of those things that gives the community a meaning and personally it makes me feel being a part of it. Thank You, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
