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

[Moritz Lennert]

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 <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/*`?

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