[GRASSLIST:10395] Re: [GRASS5] gis manager 2 rc3 - bug fixes and
michael.barton at asu.edu
Sun Feb 19 20:36:32 EST 2006
Thanks for working with the new gis.m. I should mention that the issues you
raise about screen resizing, and several similar things, are fixed in the
version I released on Friday.
That said, the general issues you raise are important. The problem with x
displays and current GRASS modules is that there is no incentive for
changing them if we continue to depend on x displays...kind of a chicken and
egg situation. So what I've tried to do is begin to create such an
incentive. Nonetheless, if it is not used on a regular basis by many people,
I'm not sure if it will be much of an incentive.
At the moment--considering that several important GRASS modules still
require x11--I don't think that we can do away with the d.m GUI. The
question is which one comes up automatically when you start GRASS in TclTk
mode? I'd vote for the new one, given the above considerations, IF (an
important 'if') it works at least as well as the old one.
There are at least three ways to measure this: does it accomplish the same
functions (or more functions); is it as easy (or easier) to use; is it as
reliable (or more reliable)?
I'm sure that it is more functional. I've also cleaned up a lot of the
code--some of which became convoluted by my enhancements over the past year
of the original much simpler display manager. It can do everything the old
d.m could do and more (e.g., better printing, independent layer trees and
region settings for each map, better thematic mapping, better text
I hope it is also easier to use. I think display controls are simpler (and
will be even more straightforward when I switch them to radio-button
behavior). Output to files or printing is more standard. There are dialogs
for setting fonts as well as colors.
Reliability is the one (important) place I am less certain of. I've been
using the newest versions of the gism2 as I develop them. Originally, errors
were unacceptably frequent for a piece of software as stable as GRASS. Over
the past couple weeks, they've dropped to near zero for me on my Mac--about
the same frequency as with the d.m (which occasionally froze too). But I'm
not as informed first hand as to how it's fairing on Linux and
Windows/Cygwin machines. Maciek has been very good in reporting errors under
Linux, and several other people have been reporting regularly. Recently,
most of the discussion has turned to functionality and ease of
use--suggesting that many/most of the bugs are cleared up.
I don't have any reports under Windows/Cygwin yet. I'd like to hear these
because Windows/Cygwin seemed to me to freeze up much more often than Mac
and Linux when I've worked with students in labs over the past year. I've
asked one of the RA's who uses Windows to see if he can run it through its
paces. I seem to remember that you use Window and Cygwin, but could be
mistaken. I'm wondering if the new version will be more stable in this
environment because it does not depend on x11 emulation. Even more
important, this GUI *should* work with the new Windows-native version of
GRASS, under TclTk for Windows--providing access to nearly all of GRASS in
this environment. But I need someone testing this new version of GRASS to
test this GUI. If it works, it would be strong incentive to make it the
default, at least in the Window-native environment. I hope that you will
continue to test and report problems (and successes) as you encounter them.
So it's not quite ready to become the GUI that automatically pops up when
you start GRASS (with d.m still available and compiled in standard GRASS
versions to anyone who wants to primarily use x displays). But I think it's
pretty close. I'm watching the bug reports on this and will be using it on a
regular basis myself. When they drop to near 0 (hopefully on this release),
I'll propose switching the default behavior to the developers group and see
what the response is. In order to develop a better user interface to GRASS,
and maintain its command-line flexibility, we need to deploy a GUI that
users want to use and that does not require interaction with the program via
the x-terminal and x-displays. We should not release any new module
prematurely (though this is being deployed in the developmental beta version
of GRASS, and not in the 'stable' version--which does not even have the
integrated GIS Manager). But when it is at least as functional as the d.m, I
think we should get this new interface into regular use in order to improve
both it and underlying C-modules
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
> From: David Finlayson <dfinlays at u.washington.edu>
> Reply-To: <dfinlays at u.washington.edu>
> Date: Sun, 19 Feb 2006 10:25:35 -0800
> To: Michael Barton <michael.barton at asu.edu>
> Cc: Glynn Clements <glynn at gclements.plus.com>, Grass Developers List
> <grass5 at grass.itc.it>, Multiple recipients of list <GRASSLIST at baylor.edu>
> Subject: Re: [GRASSLIST:10395] Re: [GRASS5] gis manager 2 rc3 - bug fixes and
> I've been following along with the CVS version of gis.m over the past
> few weeks. While I think that it is moving in the right direction, I
> don't think it is polished enough to replace the current GUI. Several
> of the "release candidates" have introduced new features, and there is
> discussion about adding still more. These aren't release candidates,
> they are proof-of-concept betas.
> Personally, I am still not happy with the way the display monitor is
> working in the new version. As of CVS last night, resizing the display
> still doesn't resize the map. As much as 50% of the area of the
> monitor is taken up by blank space. I am still getting random errors
> here and there while zooming or panning, etc.
> I understand the whole problem with the X display and the current
> generation of interactive tools is really holding back the development
> of a modern GUI on grass. But effort should be put into all of these
> areas before replacing the current GUI which, for better or worse,
> actually functions rather well with the existing system.
> This is such a lot of work that Mike has been putting into this, I
> don't want to sound ungrateful. I am just concerned that the new GUI
> is being rushed out the door before it is ready.
> On 2/18/06, Michael Barton <michael.barton at asu.edu> wrote:
>> See below.
>> Michael Barton, Professor of Anthropology
>> School of Human Evolution and Social Change
>> Arizona State University
>> Tempe, AZ 85287-2402
>> phone: 480-965-6213
>> fax: 480-965-7671
>> www: http://www.public.asu.edu/~cmbarton
>>> From: Glynn Clements <glynn at gclements.plus.com>
>>> Date: Sat, 18 Feb 2006 11:05:40 +0000
>>> To: Michael Barton <michael.barton at asu.edu>
>>> Cc: Grass Developers List <grass5 at grass.itc.it>, Multiple recipients of list
>>> <GRASSLIST at baylor.edu>
>>> Subject: Re: [GRASS5] gis manager 2 rc3 - bug fixes and updates
>>> Michael Barton wrote:
>>>> modifying zooming again. Zooming now stays on until you press the right
>>>> mouse button. This matches the other display controls. However, I agree
>>>> Glynn that this does not follow interface guidelines exactly (the right
>>>> button for Windows and Mac, at least, is reserved for contextual menus).
>>>> I don¹t have a better solution for how to stop the the action of these
>>>> for the moment. Double clicking is often used by graphic programs, but I
>>>> worry that a misplaced double click will change a zoom or pan. I could use
>>>> key-click combination, but don¹t know which, if any, are considered
>>>> for stopping tool actions (Anyone have some real information on this?). A
>>>> potentially good idea is to make the buttons work like radio buttons and
>>>> a pointer button. GIMP works this way. However, if possible, this would
>>>> some creative programming and time to do it. I¹ll keep it in mind. If
>>>> wants to tackle it....
>>> The usual mechanism is a set of radio buttons to select the current
>>> "tool". Zoom would be one of the tools.
>>> I'm not sure what you mean by "creative programming". Tk has radio
>>> buttons; for use in a toolbar/toolbox, use "-indicatoron off" to use
>>> the button's relief to reflect the activation state (rather than
>>> having a separate indicator).
>> I was thinking I'd have to program the buttons' various state
>> configurations. I'd like the buttons to have a similar appearance to what
>> they have now (with icons and the like).
>> I don't know if radio buttons can be made in that way (rather than simple
>> diamonds/circles). Maybe they can, but I haven't done it yet and would have
>> to figure it out and redo the tool bar. Also, by switching to radio buttons,
>> each button would not call a particular command, but set a variable. I
>> suppose I'd need a switch statement then to actually issue the commands.
>> Maybe this is the best way to go. It will just take some time to work it out
>> and implement it.
>>> Glynn Clements <glynn at gclements.plus.com>
> David Finlayson
> Marine Geology & Geophysics
> School of Oceanography
> Box 357940
> University of Washington
> Seattle, WA 98195-7940
> Office: Marine Sciences Building, Room 112
> Phone: (206) 616-9407
> Web: http://students.washington.edu/dfinlays
More information about the grass-dev