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 <wenzesl...@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 <bendu...@fastmail.fm>wrote: > > On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert < > 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/*`? > > >> 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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- ----
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
