16 Apr 04:30 2014
Who wants GUI and who does not and why
Vaclav Petras <wenzeslaus <at> gmail.com>
2014-04-16 02:30:57 GMT
2014-04-16 02:30:57 GMT
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,
_______________________________________________ grass-dev mailing list grass-dev <at> lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev