[GRASS-dev] CLI!=GUI

[Michael Barton]

Roger

The GUI is mostly built on top of the data analysis/management modules, but also involves coding for important GIS functions (e.g., interactive visualization, georectification and digitizing) that are not available in the analysis/management modules. My point here was that being able to compile without the GUI seems like it could be useful, but that trying to also create a modular GUI is highly impractical given the structure of the GRASS GUI, the need to run on multiple platforms, and the available programming capacity (currently at about 1.6, with TclTk being phased out and Martin running overtime at 1.5).

However, recent replies by Glynn and Hamish also have suggested the pragmatic costs of completely splitting off the GUI from the rest of the code and the very low cost of letting some of it get installed even if not used. 

As I said earlier, the release cycle is not held up by the GUI any more than it is held up by the other modules. GRASS release cycles are conservative for other reasons, with the benefit that it is a very stable platform for such a highly complex piece of software. Releases are a balance between sufficient improvements to justify a new release and a sufficiently low bug count to ensure that the software is more rather than less functional than a previous release. Looking back over the blocker and critical bugs for the 6.4 release, most in the past year were for Windows functionality. Of the others, some were GUI related, but more were in other important data analysis/management modules. In fact, we have maintained old, but functional GUI code (e.g., TclTk nviz and v.digit) so as not to hold up releases while new GUI code is being developed. 

Announcing a new release with a non-functional GUI would be disastrous for GRASS credibility because it would cripple the interactive visualization that most users associate with a modern GIS. A new release can have only new data management and analysis modules, only new GUI functions, or some combination of both. Probably the release of 6.4.1 will mainly be bug fixes in the data management and analysis modules.

Michael



On Nov 28, 2010, at 10:26 AM, Roger Miller wrote:

> 
> Aren't the GRASS native GUI's built -- like the GUI that I maintain for
> my own use -- on top of the CLI?  That implies that the CLI in any
> release has to be finalized before the GUI can be finalized.  I don't
> understand why the release of the CLI should be held up while the GUI is
> massaged into shape
> 
> Separate release cycles for the CLI and GUI would largely separate the
> two projects.  It seems like that separation would simplify project
> management rather than complicate it.
> 
> I am one of those (probably) rare users who maintains his own GUI.  I
> started developing it about 13 years ago as a few simple bash scripts to
> let me build and query relatively complicated displays.  Now it's a
> functional tcl/tk GUI.
> 
> I have carried my GUI through several CLI upgrades and the only time the
> task was particularly daunting was in the upgrade to 6.0.  The major
> revisions in the GUI design (not related at all to CLI changes) have
> been much more time-consuming.  I don't have to build all of the GRASS
> commands into my GUI or keep my GUI up to the standards that would be
> required of the GRASS GUI.  Perhaps that would make the task more
> daunting.
> 
> 
> Roger
> 
> 
> On Sat, 2010-11-27 at 10:58 -0700, Michael Barton wrote:
>> 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
>>> 
>> 
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> 
>