[GRASS-dev] default GUI

GRASS GRASS developer
1

On Sep 22, 2009, at 12:28 AM, grass-dev-request@lists.osgeo.org wrote:

Date: Tue, 22 Sep 2009 08:00:36 +0200
From: Martin Landa <landa.martin@gmail.com>
Subject: Re: [GRASS-dev] default GUI
To: Glynn Clements <glynn@gclements.plus.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID:
       <f8fe65c40909212300g3e8cdf98ve17c746207ea3e9f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2009/9/22 Glynn Clements <glynn@gclements.plus.com>:

[...]

What's the timescale for a 6.4.0 release? Is there enough time to
decouple the wx vdigit and nviz modules into separate programs? That
would eliminate the most likely source of major problems.

I don't think that there is enough time to do that. First 6.4.0 RC
12/2008, the last (RC5) 7/2009, now we have end of September - it's
seems to me as very very long time for RC stage. I was hoping that we
could release 6.4.0 in April 2009 , then in June, ... and now in
October. To have one year for RCs seems to me as too unacceptable
time... I would be happy to see 6.4.0 out and discuss if we would be
able to change release politics (releases more often, less RCs, etc.)

Initially I was not thinking about wxGUI as default for 6.4.0. Few
days ago some of devs/users started speaking about that. That's not up
me to decide, I cannot compare stability/usability of wxGUI versus
TCL/TK GUI. One of problem of the wxGUI are extensions which are not
separated from the main program (e.g. local copy of PseudoDC is used
when vector digitizer is available otherwise PseudoDC from wxPython is
used which can cause problems sometimes, etc.).

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

I agree with Martin on this. The wxPython GUI is certainly robust enough to be the default GUI for GRASS. But there are packaging and version issues that we need to solve in order to do this and not get flooded with reports of the GUI not starting or working correctly. We are close on these but not quite there.

We should fix as many outstanding bugs in the wxPython GUI as possible before a 6.4 stable release, but we should not hold up the release in order to switch default GUI's

FWIW, the TclTk GUI is also quite robust and can serve just fine for the default. The new one just does more and does it more elegantly.

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://csdc.asu.edu, http://shesc.asu.edu
    http://www.public.asu.edu/~cmbarton

2

Michael Barton wrote:

I agree with Martin on this. The wxPython GUI is certainly robust
enough to be the default GUI for GRASS.

Are you basing this on running the wx GUI on the same system that it
was compiled on? Or using binaries compiled on a different system?
Getting the former right is much easier than the latter.

But there are packaging and
version issues that we need to solve in order to do this and not get
flooded with reports of the GUI not starting or working correctly. We
are close on these but not quite there.

The problem is that if there are any compatibility issues between the
user's wx libraries and the version used for the vdigit module, it
won't just affect the vdigit module, but the whole GUI.

The vdigit module will never be entirely immune to wx compatibility
issues, or to issues caused by it using the GRASS libraries. This is
inevitable.

What isn't inevitable is inflicting these issues on the main GUI by
having it import vdigit as a module; that's just bad design.

And it's not as if this hasn't been mentioned several times since
almost as long as the vdigit module has been around.

--
Glynn Clements <glynn@gclements.plus.com>