[GRASS-dev] Who wants GUI and who does not and why

[Vaclav Petras]

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>wrote:
> On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert <
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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140415/0c5fe264/attachment.html>