[GRASS-dev] Who wants GUI and who does not and why
Benjamin Ducke
benducke at fastmail.fm
Thu Apr 17 04:16:48 PDT 2014
(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-request at lists.osgeo.org
> <mailto:grass-dev-request at lists.osgeo.org> wrote:
>
>> *From: *Yann Chemin <ychemin at gmail.com <mailto:ychemin at 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 <wenzeslaus at gmail.com <mailto:wenzeslaus at gmail.com>>
>> *Cc: *GRASS developers list <grass-dev at lists.osgeo.org
>> <mailto:grass-dev at lists.osgeo.org>>
>> *Reply-To: *<yann.chemin at gmail.com <mailto:yann.chemin at 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 <wenzeslaus at gmail.com
>> <mailto:wenzeslaus at 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 <benducke at fastmail.fm <mailto:benducke at fastmail.fm>> wrote:
>> > On Sun, Apr 13, 2014 at 11:03 AM, Moritz
>> Lennert <mlennert at club.worldonline.be
>> <mailto:mlennert at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
benducke at fastmail.fm
More information about the grass-dev
mailing list