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
