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

[Yann Chemin]

Maybe some of the earlier involved developers can share their thoughts on
the Tcl/Tk GUI and its integration, its rise and fall, why and where this
experience can lead the wxPython GUI now...


On 16 April 2014 08:00, Vaclav Petras <wenzeslaus at gmail.com> 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>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
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140416/087e6cee/attachment-0001.html>