[GRASS-dev] CLI!=GUI

[Michael Barton]

Very many parts of the GUI are closely connected because many of the important wxPython classes are reused to optimize the code and make enhancements and bug fixes easier. I found long ago that doing a comprehensive GUI for GRASS meant a very large and complexly interconnected code base that is very different from the individual modules that make up the rest of GRASS. The number of lines of code in the GUI is daunting. While I'm sure that this could be reduced somewhat, doing so is a complicated and ongoing chore. This has made coding much trickier. As Martin and I know all too well, changing something in one part can have unexpected repercussions in another part. 

At one time, when the "GUI" was simply a base menu system and independent dialogs for each command, it was possible to split out parts. With a display canvas and its associated functions (including digitizing, profiling, georectification, and 3D visualization), this would now be a great amount of work and I'm not sure that it would be worth the great effort to the majority of GRASS users given the very small number of programmers and the large amount of other work to do. 

Compiling without the GUI is a good idea. GRASS works fine without it. If you take it away now, it will simply start in text mode, but a cleaner solution is desirable. Trying to come up with a way for users to create a customized GUI that they can plug together sounds nice in theory, but in practice is very difficult. For example, a couple years back, I looked into what it would take to allow the layer manager to "dock" onto a display canvas so that GRASS could have the appearance of ArcGIS that some people favor. I found that it is possible, but would require a very large amount of rewriting of existing code. Now, it may be even more difficult. Something as complex as an interface like this is heavily affected by path dependence. We've tried to make it as robust as possible, and made a lot of good decisions about architecture early on. But there is still a lot of lock-in and interconnectivity--intentional and unintentional--that is impossible to decouple without months of programming time.

Michael



On Nov 27, 2010, at 10:00 AM, <grass-dev-request at lists.osgeo.org> wrote:

> Date: Sat, 27 Nov 2010 12:04:24 +0100
> From: "Francesco P. Lovergine" <frankie at debian.org>
> Subject: Re: [GRASS-dev] CLI!=GUI
> To: Martin Landa <landa.martin at gmail.com>
> Cc: "frankie at debian.org" <frankie at debian.org>,
> 	"grass-dev at lists.osgeo.org" <grass-dev at lists.osgeo.org>,
> 	cavallini at faunalia.it
> Message-ID: <20101127110420.GA2170 at mithrandir>
> Content-Type: text/plain; charset=us-ascii
> 
> On Sat, Nov 27, 2010 at 11:43:02AM +0100, Martin Landa wrote:
>> Hi,
>> 
>> 2010/11/27 Markus Neteler <neteler at osgeo.org>:
>>> On Sat, Nov 27, 2010 at 6:51 AM, Paolo Cavallini <cavallini at faunalia.it> wrote:
>>>> E.g., does anybody want to install libwxgtk2.8-0 on a server, where GRASS can be used
>>>> for WPS?
>>> 
>>> Likely not, but --without-wxwidgets should help.
>> 
>> it will just disable wxGUI digitizer (wxNviz has been rewritten to python).
>> 
>> We could add new flag --without-gui which would disable compiling (and
>> installing selected components).
>> 
>> martin
>> 
> 
> That would be the very first step, indeed. Of course IMHO a full solution would
> imply also:
> 
> - having a componentized GUI which could be added to the core without rebuilding
>  the whole beast (possibly componentizing 2d/3d would be also a good idea).
> - decoupling gui/core releases: my impression is that the core could evolve much
>  fastly than the gui. That's based on counting the current number of GUI related bugs 
>  in comparison with core ones. 
> 
> -- 
> Francesco P. Lovergine
>