I’m happy to see the clarifications. I’ll a few more responses and clarifications, and shut up.
Cheers
Michael
(see below)
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:
- Allow for the release stable versions of core GRASS without
having to wait for GUI fixes on different OS.
Ben
This request suggests some misunderstanding of how GRASS and its release scheduling work. We all agree that it sometimes seems to be very slow with stable releases. But this is not a CLI vs. GUI issue. In part it has to do with the history of GRASS development that (for some reason, and not entirely bad reasons) there is a tendency to have very very clean stable releases. This involves a lot of development and bug fixing because GRASS is a very large and complex software ecosystems. We don’t want to have a buggy release.
It’s up to Markus and other Lords of the Code to decide how best to handle creating stable release branches. To my understanding, we as a community decide it is time for a release (not often enough perhaps), make sure that the current development branch is as clean as possible, and freeze a snapshot of the dev branch into a release branch. Then we fix any bugs in the release branch, test, and release.
You are suggesting that we create a release branch in a somewhat more complicated way, in which some new code from the current dev branch gets merged into prior release code. Maybe that is possible, but it sounds complicated to me. I would have to defer to Markus on whether this is possible or even desirable.
The GUI does not hold up release any more or less than any other part of the code. We might as well say that we’ll release the raster/volume modules without waiting for bug fixes to vector modules. I’m not being facetious, but simply pointing out that if we are to release parts of the GRASS code base independently of other parts, there is no compelling rationale for splitting C-modules vs. wxPython GUI over 2D vs. 3D. Maybe this is a way to speed up releases but I’m skeptical.
Of course, anyone can compile any new versions of modules (or any other code) from the dev branch, merge it into release branch code, and package it up for distribution. This is a packager option, and I’ve even done that rarely when there is a critical bug fix that did not make it into a release branch.
- 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.
I agree of course
- 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.
I’m not sure how this differs from our current situation. But maybe Ana and Martin would entertain ideas on this.
If this is where things are heading anyway, then great.
Otherwise, I would like to nudge things more into the
direction mentioned above.
I think that this is overall what we are already doing and have been doing for a while now. So maybe it is just some misunderstanding of how the release process works.
From: Yann Chemin <ychemin@gmail.com>
Subject: Re: [GRASS-dev] Who wants GUI and who does not and why
Date: April 17, 2014 at 5:50:48 AM MST
To: Benjamin Ducke <benducke@fastmail.fm>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Reply-To: <yann.chemin@gmail.com>
- Allow for the release stable versions of core GRASS without
having to wait for GUI fixes on different OS.+1 for that !
I have not seen that the GUI has held up releases any more than modules. There were several years of heavy GUI development but these were also accompanied by a lot of overall code changes I’d mentioned before, including replacing all C modules that had persistent processes and changing all bash scripts to Python. This was originally planned for GRASS 7 but a lot got backported into GRASS 6. Perhaps that was a mistake. Maybe we should have kept 6 with TclTk and bash, released versions of it sooner, and moved to Python only in 7. But there were good reasons for doing as we did, too. Hindsight is 20/20 but it doesn’t help much.
From: Moritz Lennert <mlennert@club.worldonline.be>
Subject: Re: [GRASS-dev] Who wants GUI and who does not and why
Date: April 17, 2014 at 6:46:11 AM MST
To: Vaclav Petras <wenzeslaus@gmail.com>, GRASS developers list <grass-dev@lists.osgeo.org>
I agree with what Michael and Benjamin have said, but since I was cited personally just a short reaction:
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.
As I implied in the previous post, in some cases, a GUI is an alternative way of running a command and can be helpful because you don’t have to remember all the arguments and how they are spelled. In such cases, CLI and GUI implementation should be identical IMHO.
However, there are also functions that can be carried out though interactive hand/eye coordination (facilitated by a mouse, touch screen, or other device) that cannot be replicated by typing a command – especially in the visualization domain.
A GUI of some kind is also needed for certain kinds of processes now because GRASS commands no longer operate as persistent processes. As I indicated previously, we started moving over a decade ago toward giving up the old GRASS 4 and 5 commands that operated as persistent processes in exchange for much enhanced scriptability and cross-platform portability. That change helped make GRASS accessible to a much wider audience, and make it play better with other programs. That also meant that all the human-computer interaction that used to take place in commands like d.zoom, for example, had to be be moved to another programming interface. We wrote a comprehensive wxPython GUI environment in which to do this.
But of course a dedicated and inspired programmer could write a different environment for such interaction. The point is that you simply can’t fix GRASS CLI modules to do some of the things you can do in a GUI. That’s a result of the value-added aspect of a GUI. But you can write a different overlay program (i.e., sitting on top of CLI modules) that will allow users to do things like display a map on the screen through typing instead of using a mouse. Some people have already done that for some aspects of GRASS. If there is continued demand for this kind of user interface and GRASS community members who want to create it, we will see more. Personally, I hope we do see more of this. I could use such interfaces to create and manipulate GRASS visualizations during ABM runs.
Personally, I think we need to continue to be vigilant to maintain full GRASS functionality across all OS platforms. That can be tricky, especially with Windows as it is not a *nix OS. I don’t see this getting easier, but we are getting a lot better at it. One big advantage of wxPython over other interface environments is that it is much more closely and easily cross platform across Linux, Mac, and Windows than most alternatives.
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.
Indeed!
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.
I believe this is the case now, especially with GRASS 7.
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
Thanks Ben, Yann, Moritz and others
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