Re: [GRASS-dev] Who wants GUI and who does not and why
Huidae Cho wrote: I'm not talking about the current structure. Yes, the modules are the CLI right now and the GUI calls the CLI modules internally. What I'm saying is that it would great if we could separate the logic and CLI and put the logic in plugins We already do that, except that the plugins are called modules, and the calling mechanism is program execution. All of GRASS' significant functionality is in the modules. The libraries are just utilities which ensure some degree of consistency and avoid the need for modules to continually re-invent the wheel. Splitting every single module into an interface executable and a logic library amounts to a complete re-write of GRASS. Feel free to start your own fork, but don't expect everyone else to jump on board. There's also the fact that, with a persistent application, any segfault takes down the entire application, any memory leak persists for the lifetime of the application, etc. So you can't just separate the code, you also have to clean it up significantly. Actually, even now, GRASS libs are called directly from GDAL for handling raster/vector maps. That is long overdue for change. It has been problematic ever since the r.external functionality was added. Because now the GRASS libraries call GDAL, so the GDAL-GRASS bridge has to be a separate plugin to avoid a circular dependency. And if we ever removed the support for the legacy versions of the raster format from GRASS, GDAL would automatically stop supporting them as well. Now that we have r.external, the ideal solution would be to move the actual raster I/O code into GDAL itself, and perform all raster access via GDAL. I would have done it myself, except that it ideally needs to be done by two people to avoid contaminating GDAL with the GPL used by GRASS. One person would document the raster file formats, while another would write a clean implementation based upon the documentation. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
Luca Delucchi lucadel...@gmail.com writes: On 18 April 2014 11:15, Pietro peter.z...@gmail.com wrote: Hi Vaclav, actually I'm a bit more extremist... :-) I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui I also like this idea... I think this would be a very good idea as it would make the whole GRASS ecosystem more transparent and easier (in my opinion) to maintain and to use certain aspects from different applications. Re functionality in the GUI: The question would be if the split is lib--cli--gui or |--cli lib| |--gui in other words, if the cli is just a non graphical UI or THE interface to the lib, through which the gui operates. I think the first design approach would be the better one. Cheers, Rainer At least should be possible to build these parts separately, leaving the decision to split in several packages to the package maintainer of each distribution (Debian, Fedora, etc.). I think that someone is already doing something like this. But I don't know more because I usually compile myself GRASS Regards Pietro -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
I agree. grass-cli and grass-gui should be completely independent and at the same level. They are simply two different UIs that directly depend on grass-lib. The user wants either grass-cli grass-lib or grass-gui grass-lib. Now, my opinion is if we put analysis and modeling code in grass-lib, grass-lib would be too big or, for some users, it would contain too much irrelevant code if all they want is simply GIS operations. Very field-specific code such as hydrology, remote sensing, ... should be separated out from the grass-lib and put in another layer of the libraries. grass-cli/gui will interact with that layer directly. grass-lib - grass-plugins - grass-cli, grass-gui, other GISs: Full analysis/modeling suite grass-lib - other GISs: Simple GIS data manipulation very common in all fields. Regards, Huidae On Fri, May 2, 2014 at 4:32 AM, Rainer M Krug rai...@krugs.de wrote: Luca Delucchi lucadel...@gmail.com writes: On 18 April 2014 11:15, Pietro peter.z...@gmail.com wrote: Hi Vaclav, actually I'm a bit more extremist... :-) I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui I also like this idea... I think this would be a very good idea as it would make the whole GRASS ecosystem more transparent and easier (in my opinion) to maintain and to use certain aspects from different applications. Re functionality in the GUI: The question would be if the split is lib--cli--gui or |--cli lib| |--gui in other words, if the cli is just a non graphical UI or THE interface to the lib, through which the gui operates. I think the first design approach would be the better one. Cheers, Rainer At least should be possible to build these parts separately, leaving the decision to split in several packages to the package maintainer of each distribution (Debian, Fedora, etc.). I think that someone is already doing something like this. But I don't know more because I usually compile myself GRASS Regards Pietro -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
On 02/05/14 14:29, Huidae Cho wrote: I agree. grass-cli and grass-gui should be completely independent and at the same level. They are simply two different UIs that directly depend on grass-lib. The user wants either grass-cli grass-lib or grass-gui grass-lib. Now, my opinion is if we put analysis and modeling code in grass-lib, grass-lib would be too big or, for some users, it would contain too much irrelevant code if all they want is simply GIS operations. Very field-specific code such as hydrology, remote sensing, ... should be separated out from the grass-lib and put in another layer of the libraries. grass-cli/gui will interact with that layer directly. grass-lib - grass-plugins - grass-cli, grass-gui, other GISs: Full analysis/modeling suite grass-lib - other GISs: Simple GIS data manipulation very common in all fields. I don't think I understand: there is no such thing as grass-lib that can be called from either a grass-cli _or_ a grass-gui. The GUI actually calls grass modules. And these modules _are_ the CLI. And as many discussions have shown before, GRASS libs should not be called from anything else but GRASS modules. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
I'm not talking about the current structure. Yes, the modules are the CLI right now and the GUI calls the CLI modules internally. What I'm saying is that it would great if we could separate the logic and CLI and put the logic in plugins and let the CLI and GUI calls the logic. GUI would be independent on CLI and directly call the logic plugin. Here, I'm saying plugin because each module could be implemented as a mod_*.so just like Apache modules. Then we could implement a CLI environment that can load mod_*.so as needed dynamically. In the same way, other programs can call mod_*.so without creating a separate process for individual modules. Actually, even now, GRASS libs are called directly from GDAL for handling raster/vector maps. On Fri, May 2, 2014 at 9:58 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 02/05/14 14:29, Huidae Cho wrote: I agree. grass-cli and grass-gui should be completely independent and at the same level. They are simply two different UIs that directly depend on grass-lib. The user wants either grass-cli grass-lib or grass-gui grass-lib. Now, my opinion is if we put analysis and modeling code in grass-lib, grass-lib would be too big or, for some users, it would contain too much irrelevant code if all they want is simply GIS operations. Very field-specific code such as hydrology, remote sensing, ... should be separated out from the grass-lib and put in another layer of the libraries. grass-cli/gui will interact with that layer directly. grass-lib - grass-plugins - grass-cli, grass-gui, other GISs: Full analysis/modeling suite grass-lib - other GISs: Simple GIS data manipulation very common in all fields. I don't think I understand: there is no such thing as grass-lib that can be called from either a grass-cli _or_ a grass-gui. The GUI actually calls grass modules. And these modules _are_ the CLI. And as many discussions have shown before, GRASS libs should not be called from anything else but GRASS modules. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
On Fri, May 2, 2014 at 10:03 AM, Vaclav Petras wenzesl...@gmail.com wrote: On Fri, May 2, 2014 at 8:29 AM, Huidae Cho gras...@gmail.com wrote: I agree. grass-cli and grass-gui should be completely independent and at the same level. They are simply two different UIs that directly depend on grass-lib. The user wants either grass-cli grass-lib or grass-gui grass-lib. This of course makes sense. However, we are very far from anything like this. Functionality is in the modules (i.e. CLI), not library, and even Python libraries contains CLI calls. I don't see any chance of changing this state any time soon, although it would be beneficial. The grass-lib would no just contain very basic things (compared to what CLI would provide). Consequently there cannot be any GUI without CLI now. That's correctly. GUI is a wrapper around CLI because CLI has the logic. Other programs that want to use GRASS capabilities should also call CLIs by executing external programs (CLIs). Instead of calling external processes, we could dynamically link to the logic libraries and simply call functions if we could do further separations. Now, my opinion is if we put analysis and modeling code in grass-lib, grass-lib would be too big or, for some users, it would contain too much irrelevant code if all they want is simply GIS operations. Very field-specific code such as hydrology, remote sensing, ... should be separated out from the grass-lib and put in another layer of the libraries. grass-cli/gui will interact with that layer directly. As I said this is very theoretical and in fact, there was one refactoring which moved things from lib to modules. Anyway, it would be beneficial to know what would be concrete steps to do this, what are the issues this must solve, and, similarly to GUI, what is the general opinion on this. For example, the implementation of RPC interface for library (as discussed in another threads) would allow usage of grass-lib by any application, not only modules (CLI), so then GUI could depend directly on grass-lib. On the other hand, modules define a nice user interface for processing, so I don't think that GUI should define some other, it should just use the modules (the current state). The other question is what should be used to implement GUI. Regardless of purpose of grass-lib, there are some thing which should be moved to the library to be reused in more modules. Pietro recently suggested in some ticket that functionality of r.univar should be available in the library. grass-lib - grass-plugins - grass-cli, grass-gui, other GISs: Full analysis/modeling suite I still don't understand what do you mean by grass-plugins. What I mean by grass-plugins is that we can separate the current CLIs (UI and logic) into plugins (logic) and light-weight CLI that calls the plugins. GUI would also call the plugins. Think about Apache. httpd is an executable file that can load its modules as needed. We cannot call individual modules directly without using httpd and individual modules have the logic. I think that this plugin idea would make GRASS analysis/modeling capabilities more like libraries, not external programs, while maintaining clear separation of heavy analysis logic from the core grass-lib. And like you said, yes, we're far from this theoretical status. Huidae Vaclav grass-lib - other GISs: Simple GIS data manipulation very common in all fields. Regards, Huidae On Fri, May 2, 2014 at 4:32 AM, Rainer M Krug rai...@krugs.de wrote: Luca Delucchi lucadel...@gmail.com writes: On 18 April 2014 11:15, Pietro peter.z...@gmail.com wrote: Hi Vaclav, actually I'm a bit more extremist... :-) I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui I also like this idea... I think this would be a very good idea as it would make the whole GRASS ecosystem more transparent and easier (in my opinion) to maintain and to use certain aspects from different applications. Re functionality in the GUI: The question would be if the split is lib--cli--gui or |--cli lib| |--gui in other words, if the cli is just a non graphical UI or THE interface to the lib, through which the gui operates. I think the first design approach would be the better one. Cheers, Rainer At least should be possible to build these parts separately, leaving the decision to split in several packages to the package maintainer of each distribution (Debian, Fedora, etc.). I think that someone is already doing something like this. But I don't know more because I usually compile myself GRASS Regards Pietro -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10
Re: [GRASS-dev] Who wants GUI and who does not and why
Hi, if you allow me a user comment on this: The user wants either grass-cli grass-lib or grass-gui grass-lib. Actually, the combination of CLI and GUI is extremely handy in everyday work, which is why I regularly introduce students quite early to this combination. The possibility to copy the commands from GUI is here very helpful too. I missed having a CLI in parallel on Windows until it came with GRASS 7. Before I regularly started two grass sessions. First the GUI then the command line. It would be a pity if this perfectly matched team would be separated (in terms of user experience)… Cheers Stefan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
I really like this idea and want to go further by splitting into four main parts: - grass-lib: keep the current core libraries as is. Low level GIS layer - grass-plugins: implement raster/raster3d/vector/... whatever the current commands implement as libraries. These libraries spit out xml for building CLI/GUI interfaces. One plugin per module. High level modeling/analysis layer - grass-cli: very light xml parser. Maybe, we'll only need one command and give a plugin name and its parameters to this command. - grass-gui: also very light xml parser. This way, other GIS programs can use grass-lib and grass-plugins to build their interface from xml output without having to update their client code heavily whenever a major GRASS GIS is released. Regards, Huidae On Fri, Apr 18, 2014 at 5:15 AM, Pietro peter.z...@gmail.com wrote: Hi Vaclav, actually I'm a bit more extremist... :-) I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui often we have these things mixed to each other, for example a lot of GRASS modules implement functions that could be moved to grass/lib (e.g. r.stats). I would like to see the CLI interface just only as command line interface to the GRASS library, not more not less. At the moment each GRASS module implement it's own functions. The same is true for the GUI, inside the GUI libraries there are a lot of functions and objects that partially implement functionality that should be moved to lib. Again I would like a clearer distinction between the logic/functionality and Graphic user interface. These changes could help to reduce redundancy and reduce the code size of the GRASS project. Split the GRASS project in these three parts perhaps could help us to clearly distinguish between functionalities and interfaces (command/graphic),and we should re-organize the grass root consistently. Splitting the library from the CLI, should make easier other FOSS projects to use the GRASS processing capabilities. At least should be possible to build these parts separately, leaving the decision to split in several packages to the package maintainer of each distribution (Debian, Fedora, etc.). Regards Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
Hi, Ubuntu follows debian packaging for GRASS GIS like others. And most of the packaging rules are copied from DebianGIS. So for debian, and its derivaties. GRASS packaging has grass-core, grass-gui, grass-docs, packages grass-dev. too is there for development version. On Sun, Apr 20, 2014 at 1:42 AM, Luca Delucchi lucadel...@gmail.com wrote: On 18 April 2014 11:15, Pietro peter.z...@gmail.com wrote: Hi Vaclav, actually I'm a bit more extremist... :-) I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui I also like this idea... At least should be possible to build these parts separately, leaving the decision to split in several packages to the package maintainer of each distribution (Debian, Fedora, etc.). I think that someone is already doing something like this. But I don't know more because I usually compile myself GRASS Regards Pietro -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Regards, Rashad ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
On 18 April 2014 11:15, Pietro peter.z...@gmail.com wrote: Hi Vaclav, actually I'm a bit more extremist... :-) I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui I also like this idea... At least should be possible to build these parts separately, leaving the decision to split in several packages to the package maintainer of each distribution (Debian, Fedora, etc.). I think that someone is already doing something like this. But I don't know more because I usually compile myself GRASS Regards Pietro -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
Hi Vaclav, actually I'm a bit more extremist... :-) I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui often we have these things mixed to each other, for example a lot of GRASS modules implement functions that could be moved to grass/lib (e.g. r.stats). I would like to see the CLI interface just only as command line interface to the GRASS library, not more not less. At the moment each GRASS module implement it's own functions. The same is true for the GUI, inside the GUI libraries there are a lot of functions and objects that partially implement functionality that should be moved to lib. Again I would like a clearer distinction between the logic/functionality and Graphic user interface. These changes could help to reduce redundancy and reduce the code size of the GRASS project. Split the GRASS project in these three parts perhaps could help us to clearly distinguish between functionalities and interfaces (command/graphic),and we should re-organize the grass root consistently. Splitting the library from the CLI, should make easier other FOSS projects to use the GRASS processing capabilities. At least should be possible to build these parts separately, leaving the decision to split in several packages to the package maintainer of each distribution (Debian, Fedora, etc.). Regards Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
Hi, 2014-04-18 11:15 GMT+02:00 Pietro peter.z...@gmail.com: I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui I was thinking about splitting `grass` package at least manually for OSGeo4W framework. This idea makes sense to me. Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
, 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, grass-dev-requ...@lists.osgeo.orgmailto:grass-dev-requ...@lists.osgeo.org wrote: From: Yann Chemin yche...@gmail.commailto:yche...@gmail.com 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 wenzesl...@gmail.commailto:wenzesl...@gmail.com Cc: GRASS developers list grass-dev@lists.osgeo.orgmailto:grass-dev@lists.osgeo.org Reply-To: yann.che...@gmail.commailto:yann.che...@gmail.com 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 wenzesl...@gmail.commailto:wenzesl...@gmail.com 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 bendu...@fastmail.fmmailto:bendu...@fastmail.fm wrote: On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert mlenn...@club.worldonline.bemailto:mlenn...@club.worldonline.be 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 grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
(sorry for the extensive cutting) On 17/04/14 08:41, Michael Barton wrote: [..] 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? I fear that this discussion is leading somewhere bad... Perhaps the title of this post was a bit misleading. At least from my point of view, we do not need to discuss whether GRASS needs a GUI or not. As Michael correctly states: whatever the community invests in will stay. There are probably as many different preferences for user interfaces as there are GRASS users, so any discussions on whether there are enough GUIs or which one is be the best, or whether it is better to work from the CLI, etc. are moot. What I wanted to suggest was merely to separate the GRASS core from the GUI development even more. Yes, it is true that this has been done at source code level, but my wishes would be that we end up in a situation that will: 1. Allow for the release stable versions of core GRASS without having to wait for GUI fixes on different OS. 2. Always make people think twice about module/GUI interaction when something doesn't work as smoothly as expected, so that we always end up with a clean solution that works in a GUI and CLI environment. 3. Leave the GUI developers more freedom to find hacks and work-arounds for certain issues that are fine for a controlled, monolithic GUI, but not for CLI GRASS. If this is where things are heading anyway, then great. Otherwise, I would like to nudge things more into the direction mentioned above. Best, Ben 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, grass-dev-requ...@lists.osgeo.org mailto:grass-dev-requ...@lists.osgeo.org wrote: *From: *Yann Chemin yche...@gmail.com mailto:yche...@gmail.com *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 wenzesl...@gmail.com mailto:wenzesl...@gmail.com *Cc: *GRASS developers list grass-dev@lists.osgeo.org mailto:grass-dev@lists.osgeo.org *Reply-To: *yann.che...@gmail.com mailto:yann.che...@gmail.com 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 wenzesl...@gmail.com mailto:wenzesl...@gmail.com 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
Re: [GRASS-dev] Who wants GUI and who does not and why
1. Allow for the release stable versions of core GRASS without having to wait for GUI fixes on different OS. +1 for that ! ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
I agree with what Michael and Benjamin have said, but since I was cited personally just a short reaction: On 16/04/14 04:30, Vaclav Petras 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 bendu...@fastmail.fm mailto:bendu...@fastmail.fm wrote: On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be 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/*`? I don't know how you come to that conclusion from the above quote. I never saif I don't want the GUI. What I refered to was a recurrent discussion about making sur that all functionality for which this is possible should be available via the CLI, and not only via the GUI. Just to cite one example which shows some degree of divergence: The GUI import wizards (vector and raster) allow specifying a directory from which to import all (or a selection) of the files. AFAIK, there is no command line equivalent for that, except for creating the loop yourself in your favorite scripting language. So, to follow my idea, we should have a r.in.gdal.dir/v.in.ogr.dir module which does the job on the command line and which the GUI builds upon. I know: if it's an itch just scratch it yourself, but I'm just using this an example to illustrate the quote above. And it's not meant as a criticism to anyone, but rather as a reminder to ourselves to be vigilant about this. The recent creation of the g.gui.* commands is a good step in the other direction, i.e. making small modules of specific GUI processes. 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. This is _your_ conclusion, although others have had that same conclusion before, but, as Michael has argued convincingly, there are sufficient developers who want to spend time on a specific GRASS GUI as they feel the need, and so the discussion is void. I personally certainly find the GRASS GUI very useful, and have never been able to warm up to using QGIS or gvSIG for the task, notably because of the loss of explicit control over the whole location management (in Sextante and derivatives) which I actually find very useful when teaching (and using) GIS. I also think that some of the debate comes from the question of whether the wxGUI should have a special status or whether it should just be treated as one of the hundreds of modules that GRASS offers. This is more or less the current state, there is g.gui, you can start without it, there are g.gui.* modules. On the other hand, there is always something spatial with GUI, e.g. if you want GUI to start when module is started without parameters/with --ui. All that was meant by the above statement is that specific needs of the wxGUI should not interfere in overall management of GRASS installation and compilation any more than other modules. Or, are you satisfied with the situation as it is now? In terms of the fact that we have a wxGUI I'm very satisfied. The discussion you cite has never been about abandoning the GUI, but about how to handle GRASS installation. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
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 wenzesl...@gmail.com 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 bendu...@fastmail.fmwrote: On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert mlenn...@club.worldonline.be 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 OSGeo could save some work. For example, QGIS GRASS plugin is developed separately, so there is no need to have another graphical user interface for GRASS with disconnect development. I also think that some of the debate comes from the question of whether the wxGUI should have a special status or whether it should just be treated as one of the hundreds of modules that GRASS offers. This is more or less the current state, there is g.gui, you can start without it, there are g.gui.* modules. On the other hand, there is always something spatial with GUI, e.g. if you want GUI to start when module is started without parameters/with --ui. Or, are you satisfied with the situation as it is now? Thanks for sharing your thoughts, Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
