6.4 was delayed to make it work on Windows. This included making a useable CLI for Windows. I don't use Windows but many many people do. Making GRASS work on Windows has been very very difficult, especially because of the recursive problem that there are few GRASS developers with Windows expertise because GRASS didn't run on Windows. Going through the pain of making this work greatly expanded the potential user base and potential developer base.The reason that GRASS can run on Windows is in a large part due to a complete restructuring of the user interface away from requiring X-Windows. That is, there was no way to use GRASS or visualize the results in a Windows environment until the co-development of the new GUI (beginning with TclTk in 6.3) and display drivers.
There is nothing inherently wrong with releasing different parts of GRASS at different times.But trying to manage a single release cycle for GRASS has been pretty complicated and my hat is off to Markus. Trying to manage multiple release cycles would be more complicated. Some of the 6.4 blockers were with the GUI, but others were with the underlying modules (all of which run in CLI or GUI). For better of for worse, GRASS has a very conservative release cycle. This is because of the developer culture, not because of the GUI.
Like Martin said, because GRASS is modular, anyone can compile it or use it with or without the GUI. I use it heavily with the GUI for some things. For others, I use it completely scripted, without any GUI, and called from a completely different environment. This kind of flexibility is a real value for this piece of software.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
On Nov 21, 2010, at 10:00 AM, <grass-dev-request@lists.osgeo.org> wrote:
Message: 4
Date: Sun, 21 Nov 2010 10:24:02 +0100
From: "Francesco P. Lovergine" <frankie@debian.org>
Subject: Re: [GRASS-dev] CLI!=GUI
To: grass-dev@lists.osgeo.org
Message-ID: <20101121092402.GB2278@frankie.is-a-geek.org>
Content-Type: text/plain; charset=us-asciiOn Sat, Nov 20, 2010 at 10:49:05PM +0100, Martin Landa wrote:
Hi,
2010/11/20 Paolo Cavallini <cavallini@faunalia.it>:
I know it's an old thread, and that not everybody agrees, but I still think, after
talking with people more knowledgeable than me, that separating the core of GRASS
(libraries+CLI) from the GUI(s) will make the release and packaging process faster
and smoother, and the integration with other software, both desktop and web, easier
and cleaner.
Can we revive the discussion about this?well, my option is very subjective - wxGUI is going to be a solid GUI
for GRASS. Anyone can build it's own GRASS distribution without any
GUI (libraries and subset of the GRASS modules). But it's not task for
the core GRASS developers. They are creating solid environment ---
GRASS libraries + modules (CLI) and also the GUI. Feel free to take
what you what from this composition.Martin
What Paolo is probably trying (also?) to say is that GUIs and core could
have completely different release cycles. The GUI should be a component
like any other, to be released when ready, but that should not become
a permanent blocker of the release process, like did happen in the
6.4 release. Many people (like me and many other) use Grass as a
scripting language and are completely uninterested in having a stable
GUI at all, but are interested in having a working stable core in
reasonable times. Of course, IMHO applies.--
Francesco P. Lovergine------------------------------
: packagers, please have your saying here.