<div dir="ltr"><div>Hi all,<br></div><div><br></div><div><div class="gmail_extra">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".</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Here are recent quotations from "Handling of Python scripts on MS Windows" discussion (<a href="http://lists.osgeo.org/pipermail/grass-dev/2014-April/068269.html" target="_blank">http://lists.osgeo.org/pipermail/grass-dev/2014-April/068269.html</a>) with few notes and questions but feel free to start wherever you want.</div>

<div><br></div>

<div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 13, 2014 at 12:52 PM, Benjamin Ducke <span dir="ltr"><<a href="mailto:benducke@fastmail.fm" target="_blank">benducke@fastmail.fm</a>></span> wrote:</div>



<div class="gmail_quote">> On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<div><div>> [Side note: The same discussion should also constantly be held about<br>
> functionality which is specific to the GUI, because specifically<br>
> developed for it), i.e. not just a GUI layer above command line<br>
> functionality, something I'm afraid to see creep in more and more...]<br>
><br>
<br></div></div></blockquote><div>Does this mean that you want remove everything from `gui/*` besides `gui/wxpython/forms/*`?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<div><div>
</div></div>Agreed. Once more, I plead for a clean separation between GUI<br>
and CLI developments, and a disconnection of their release cycles.<br></blockquote><div><br></div><div>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.</div>



<div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


The wxPython GUI can be considered a monolithic application,<br>
and FWIW it can pull every trick in the book to integrate a<br>
Python interpreter, and to make it all easier for Windows users.<br><div><br>...<br>
<br>
</div>I would say: Consider the wxGUI, the QGIS and gvSIG plug-ins etc.<br>
monolithic applications and let their maintainers figure out how<br>
to deal with this. In the gvSIG CE project, we do a lot of hair-<br>
raising stuff to hide the complexity of GRASS and its dependencies<br>
from the end user, and I suspect so does QGIS. But I would not<br>
advocate the same approach to the core GRASS architecture.</blockquote></div><br>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.</div>


<div class="gmail_extra">
<br></div><div class="gmail_extra">> <span style="font-family:arial,sans-serif;font-size:13px">I also think that some of the debate comes from the question of whether</span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">> the wxGUI should have a special status or whether it should just</span></div>

<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">> be treated as one of the hundreds of modules that GRASS offers.</span></div><div class="gmail_extra"><br></div><div class="gmail_extra">

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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Or, are you satisfied with the situation as it is now?</div><div class="gmail_extra"><br></div>

<div class="gmail_extra">Thanks for sharing your thoughts,</div><div class="gmail_extra">Vaclav</div></div></div>