I’m not sure why we are having this discussion. But I’ll add some historical perspective as well as some thoughts about interfaces. So here is my 2¢ ++
When I started using GRASS in 2003, I wrote what I thought was a very polite and tactful letter to Markus saying that I though GRASS had a lot of potential but could benefit from a user interface. He wrote me back a brief and polite letter explaining that GRASS was an open source project that depended on volunteer effort. He told me that if I thought GRASS needed a better user interface, perhaps I should make it. I didn’t dare write Markus again for many months. When I did I asked about an unused preliminary framework for a menu system, called Tclgrass (“tickle-grass). It used a TclTk script to parse text files for each command to create a simple dialog for running the command. It only had some of the commands, and some were duplicated in multiple places. I went through every command in GRASS and created the needed associated text files for each one, I reorganized the menu bar, and created pull-down menu entries for each command. Radim Blazek had created another TclTk script to create the display manager, a simple GUI to some of the display (d.*) commands combined with a map display window. I used code from the display manager to add a display window to the menu system, and the first comprehensive GRASS GUI was born. The GRASS GUI has evolved a lot since this first version, has been re-written in wxPython, and has been the collaborative effort of many people over the course of a decade. Around 2005, a conscious, community decision was made to switch the GUI from TclTk to wxPython and, at the same time, switch from bash to Python as the default scripting language (I have an archive of the discussions). This made possible numerous interface advances and a much better interface design than before. A lot of thought and sophisticated design concepts have gone into the GUI development over the years, and continues today. This bit of history makes an important point. We have a GUI because some of the GRASS community felt that GRASS needed one, and put in the volunteer effort to create one. As long as we have a portion of the community that believes a the kind of program control and interactive visualization provided by a GUI is important and is willing to put in the work to develop and maintain it, we SHOULD have a GUI. If GRASS and its community evolves to a place where no one feels a GUI is needed and no one is willing to develop or maintain it, it will fade away. I cannot fathom why some members of the GRASS user and developer community would want to tell other members to stop contributing to GRASS development. A group of volunteer developers created an advanced, well-designed, fast, and smoothly working GUI to some of the most complex geospatial software available, and some users are asking those of us who have put a lot of thought and effort into this to ditch it because they like to type or because they prefer another GIS program? Part of this discussion seems to also involve requests to decouple the GUI from GRASS. I’m baffled by this. The current iteration of GRASS 7 finally DOES decouple the GUI from the CLI modules for the first time in GRASS history. This is a goal we’ve been working towards since the last TclTk GUI, and an underlying premise of the current wxPython GUI. In pre-GUI GRASS (version 5.0 and earlier), GUI functions were mixed in various and inconsistent ways with the CLI modules—especially the display modules. You would launch one of these modules with a command, then interact with the process through responding to queries through typing and/or using a mouse. This arrangement had several consequences. One was that most of these CLI/GUI modules could not be scripted. You can’t easily use a module in a script if it must wait for user input. Another consequence was that GRASS required a rather primitive X11 based display terminal. This prevented GRASS from running native under Windows and made it more complicated on the Mac. Thanks in a large part Glynn’s coordination and leadership, all GRASS CLI modules in GRASS 7 accept only arguments defined at runtime. No more persistent processes from the CLI modules. They do what they are supposed to do and terminate without further user input. They do not require a user to click something with a mouse or type an answer to a query. This makes them MUCH easier to use in scripts written in any language, including in a GUI environment. This has allowed GRASS to run natively in Windows, as well as made possible the kinds of coupled modeling environments that I am using in my research (e.g., GRASS command modules are called from a JAVA ABM and the results returned to the ABM). There is no release schedule for CLI or GUI development. Different CLI modules are developed and maintained (or not) by different people. The GUI has been developed and maintained by people who are not doing CLI development. Neither area of development impedes releases any more than any other. FWIW, the problems with GRASS and Python under Windows are more related to the ability to script GRASS modules in Python than to the GUI. When I started using and developing for GRASS in 2003, relatively few people used GRASS. Now it is used by very many. We do not collect any of the needed information to assess how much of this increase is attributable to GRASS having a modern, very useable, GUI but I suspect that it is significant. Certainly in my interactions with people, it is the ability to use GRASS through the GUI not the CLI that attracts users. It has made it possible for me to teach GIS with GRASS. All modern OS interfaces and software are heavily invested in GUI because people find them very useful, not because they have been foisted on us by clever marketers. Software users are not clamoring for more command line tools. I learned WordStar and its commands long ago and I much prefer writing with LibreOffice of today. I use the command line and encourage my students to do so too when it makes their work easier and more efficient. BUT it can be really handy to have a GUI to help me remember commands. For example, I use Climate Data Operators (CDO), which are really slick command line tools for rapidly processing very large NetCDF files. They are easy to use commands. Nevertheless, I do not use them every day and there are very many of them. So any time I want to use them, I have to go to the manual and look up the exact name of the command and its arguments. Then I have to cut and past or do a lot of typing to input the paths to the files I need to process. A GUI to CDO would make it a lot easier and quick for me to use them. Judging from the questions on the GRASS user list, I’m one of the few people who has tried almost every GRASS command. But there are well over 300 commands with a lot of different arguments. While I always type g.region -g to check region settings, I regularly use the GUI to help me properly specify the many other commands that I use less often and their many arguments. A GUI is handy and helps me get my research done more efficiently. Beyond this, interactive visualization is an important component of modern geospatial analysis. Well-designed GUI’s promote hand/eye interaction as an important means of data exploration and pattern recognition. Humans are biologically adapted to manipulate their world through hand-eye coordination, and modern GUIs leverage that capability. Such interactive visualization is becoming an increasingly important tool for big data analysis. This is especially important as GIS moves from simple 2D cartography to multidimensional analysis. Helena has been at the forefront of designing and exploring new ways for people to interact visually and tactilely with geospatial information. You MUST have some kind of GUI to do this. While the current GRASS interface is pretty advanced in this regard, especially in comparison with other GIS software, its mouse-based GUI is no longer at the cutting edge. The kinds of interaction pioneered on Apple’s iPad and being explored using Microsoft’s Kinect show even more promise for the kinds of data being managed in the GRASS Temporal GIS formats for example. So why should we abandon and discard the advances in interactive geospatial analysis and visualization pioneered by GRASS (e.g., the tightly integrated 2D and 3D interfaces, or the new interactive visualizations for remote sensing analysis)? If you like another GUI, like QGIS or gvSIG, by all means use it. Such diversity encourages innovations. But why advocate throwing away the software interface development in GRASS and relegate it to only the analytical modules that are plug-ins to other programs? Finally, unlike many other programs, users can avoid the GUI altogether GRASS. They can run GRASS with only the command line. All GRASS analytical modules can be run from the CLI and are fully scriptable, so that they can be embedded into other programs as well as run interactively. Moreover, the GUI dialogs to all modules can generate the commands to be used in the terminal. Given this flexibility, why get rid of a part of the GRASS package that makes the program very attractive and useable to a substantial number of the community? This thread pops up from time to time, and I wonder why each time. It is like saying that GRASS developers should abandon work on vector processing modules because GRASS does such a good job at rasters, and other programs like ArcGIS and QGIS do vectors better. GRASS is such great software because, like all great open source programs, it is the volunteer work of many practicing scientists who are solving problems through computation and sharing their solutions with others. It is this bottom-up development, instead of a top-down business model, that creates an ecosystem of constantly evolving—and improving—computational tools to meet changing research needs. So it should not be a question of whether some, or even a lot, of the GRASS user community wants a GUI or not, nor whether there are good usability and analytical reasons to have a GUI or not. GRASS should have a GUI if a sufficient number of users want such an interface and are willing to do the work of creating one, and do not prevent other users from accessing GRASS through a CLI. Michael ____________________ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Apr 16, 2014, at 5:22 AM, [email protected]<mailto:[email protected]> wrote: From: Yann Chemin <[email protected]<mailto:[email protected]>> Subject: Re: [GRASS-dev] Who wants GUI and who does not and why Date: April 16, 2014 at 5:20:59 AM MST To: Vaclav Petras <[email protected]<mailto:[email protected]>> Cc: GRASS developers list <[email protected]<mailto:[email protected]>> Reply-To: <[email protected]<mailto:[email protected]>> Maybe some of the earlier involved developers can share their thoughts on the Tcl/Tk GUI and its integration, its rise and fall, why and where this experience can lead the wxPython GUI now... On 16 April 2014 08:00, Vaclav Petras <[email protected]<mailto:[email protected]>> wrote: Hi all, I believe, I was calling for this discussion recently, and I'm calling for it again. It seems that there are quite different opinions on GRASS GIS GUI ranging from "GUI is the only thing which brings us new users" to "no GUI needed". There is no better time to discuss this: we are discussing issues with MS Windows support, planing to release 7, working towards compatibility of 7 with QGIS and gvSIG, and we also discussed WebGRASS topic recently. Here are recent quotations from "Handling of Python scripts on MS Windows" discussion (http://lists.osgeo.org/pipermail/grass-dev/2014-April/068269.html) with few notes and questions but feel free to start wherever you want. On Sun, Apr 13, 2014 at 12:52 PM, Benjamin Ducke <[email protected]<mailto:[email protected]>> wrote: > On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert > <[email protected]<mailto:[email protected]>> wrote: > [Side note: The same discussion should also constantly be held about > functionality which is specific to the GUI, because specifically > developed for it), i.e. not just a GUI layer above command line > functionality, something I'm afraid to see creep in more and more...] > Does this mean that you want remove everything from `gui/*` besides `gui/wxpython/forms/*`? Agreed. Once more, I plead for a clean separation between GUI and CLI developments, and a disconnection of their release cycles. I see some advantages, for example just using same bug tracker makes difficult to say what is critical issue; but there are some GUI errors are tightly coupled to core module issues. On the other hand, I don't see how these disconnected release cycles would work. Also it seems that it is impossible or very hard to create good GUI without the support of the processing and management tools. The wxPython GUI can be considered a monolithic application, and FWIW it can pull every trick in the book to integrate a Python interpreter, and to make it all easier for Windows users. ... I would say: Consider the wxGUI, the QGIS and gvSIG plug-ins etc. monolithic applications and let their maintainers figure out how to deal with this. In the gvSIG CE project, we do a lot of hair- raising stuff to hide the complexity of GRASS and its dependencies from the end user, and I suspect so does QGIS. But I would not advocate the same approach to the core GRASS architecture. Than perhaps, no wxGUI is needed because we have QGIS and gvSIG plugins. Managing one GUI less in
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
