[GRASS-dev] CLI!=GUI

[Roger Miller]

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
>