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, <[email protected]> wrote: > > Message: 4 > Date: Sun, 21 Nov 2010 10:24:02 +0100 > From: "Francesco P. Lovergine" <[email protected]> > Subject: Re: [GRASS-dev] CLI!=GUI > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > On Sat, Nov 20, 2010 at 10:49:05PM +0100, Martin Landa wrote: >> Hi, >> >> 2010/11/20 Paolo Cavallini <[email protected]>: >> >>> 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 > > > ------------------------------ _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
