[GRASSLIST:10395] Re: [GRASS5] gis manager 2 rc3 - bug fixes and updates

GRASS GIS GRASS GIS developer
1

David,

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
rendering).

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

Thanks again
Michael
__________________________________________
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: David Finlayson <dfinlays@u.washington.edu>
Reply-To: <dfinlays@u.washington.edu>
Date: Sun, 19 Feb 2006 10:25:35 -0800
To: Michael Barton <michael.barton@asu.edu>
Cc: Glynn Clements <glynn@gclements.plus.com>, Grass Developers List
<grass5@grass.itc.it>, Multiple recipients of list <GRASSLIST@baylor.edu>
Subject: Re: [GRASSLIST:10395] Re: [GRASS5] gis manager 2 rc3 - bug fixes and
updates

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@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@gclements.plus.com>
Date: Sat, 18 Feb 2006 11:05:40 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: Grass Developers List <grass5@grass.itc.it>, Multiple recipients of list
<GRASSLIST@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
with
Glynn that this does not follow interface guidelines exactly (the right
button for Windows and Mac, at least, is reserved for contextual menus).
But
I don¹t have a better solution for how to stop the the action of these
tools
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
a
key-click combination, but don¹t know which, if any, are considered
standard
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
add
a pointer button. GIMP works this way. However, if possible, this would
take
some creative programming and time to do it. I¹ll keep it in mind. If
anyone
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.

Cheers,
Michael

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

--
David Finlayson
Marine Geology & Geophysics
School of Oceanography
Box 357940
University of Washington
Seattle, WA 98195-7940
USA

Office: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays

2

Michael, David,

Glad to see how gis.m is progressing and that my input is found
somewhat hellpful.

I woould like only to comment on this 3/2 mouse button which hhas been
already talked about a bit:

2) Please don't depend (I didn't say don't use ever) on a 3-button
mouse! Most laptop keypads only have 2 buttons! I can't use it without
bringing along a real 3-button mouse. That's hard to use on an
airplane or bus.

I think Grass is not targeted at mobile computers. Defaulting to a 3
button mouse is sane IMVHO. Even if one is using laptop, relying on a
touchpad for working with GIS on his machine is not a good idea. It is
too uncomfortable - good enough for browsing the net but won't ever do
for image manipulation, drawing etc.

I'm using laptop myself most of the time and I wouldn't even consider
using Grass display stuff without a mouse. Same for Gimp or Inkscape.

Using Grass with a 3 button mouse is more powerfull when compared to 2
button mouse. Sure I'm talking from my very personnal POV but I guess it
is an issue to discuss.

I recall Glynn suggested combination of 2 button mouse and keyboard.
That could be good solutiun but is it possible to implement within
current gis.m?

Best,
Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

3

Maciek Sieczka wrote:

I recall Glynn suggested combination of 2 button mouse and keyboard.
That could be good solutiun but is it possible to implement within
current gis.m?

Yes. One of the major drawbacks of using the display architecture as a
GUI toolkit is that the only form of user input available is
unmodified mouse buttons. Tcl/Tk has no such restrictions; you can
receive key events, as well as obtaining the modifier state for mouse
events.

There's no reason why a decent GUI can't be made which only uses the
left mouse button, with the right mouse button reserved for a context
menu, and the middle button only used for functionality which can be
obtained by other means. All modern Windows applications manage to
work that way.

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

4

As Glynn indicates, TclTk is very flexible in terms of user input options
(mouse buttons, key combinations, etc.). If it becomes necessary to use a
right mouse button (or mouse button-key combination) if needed to control a
tool.

However, the objective is to make the user access to GRASS's power as simple
and straightforward as possible. That is, to get work done without having to
think about how to work the program overly much. To this end, it is good to
avoid non-standard input methods as much as possible and provide clear user
feedback on tool operation--while still maintaining their function in an
efficient manner. Using a radio-button behavior for map display buttons
(like GIMP, as someone suggested) makes it possible to achieve this for
current display tools while using only the left mouse button and not
requiring extra clicks for experienced users.

I'll do this when I get back to my office on Tuesday.

Michael
__________________________________________
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@gclements.plus.com>
Date: Mon, 20 Feb 2006 10:59:12 +0000
To: Maciek Sieczka <werchowyna@epf.pl>
Cc: David Finlayson <david.p.finlayson@gmail.com>, <michael.barton@asu.edu>,
<grass5@grass.itc.it>, <GRASSLIST@baylor.edu>
Subject: Re: [GRASSLIST:10423] Re: [GRASS5] gis manager 2 rc3 - bug fixes and
updates

Maciek Sieczka wrote:

I recall Glynn suggested combination of 2 button mouse and keyboard.
That could be good solutiun but is it possible to implement within
current gis.m?

Yes. One of the major drawbacks of using the display architecture as a
GUI toolkit is that the only form of user input available is
unmodified mouse buttons. Tcl/Tk has no such restrictions; you can
receive key events, as well as obtaining the modifier state for mouse
events.

There's no reason why a decent GUI can't be made which only uses the
left mouse button, with the right mouse button reserved for a context
menu, and the middle button only used for functionality which can be
obtained by other means. All modern Windows applications manage to
work that way.

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

5

Michael Barton wrote:

As Glynn indicates, TclTk is very flexible in terms of user input options
(mouse buttons, key combinations, etc.). If it becomes necessary to use a
right mouse button (or mouse button-key combination) if needed to control a
tool.

However, the objective is to make the user access to GRASS's power as simple
and straightforward as possible. That is, to get work done without having to
think about how to work the program overly much. To this end, it is good to
avoid non-standard input methods as much as possible and provide clear user
feedback on tool operation--while still maintaining their function in an
efficient manner.

One feature which I don't think that Tk provides is detecting key
press events for modifier keys themselves. This means that you can't
change the cursor depending upon the state of the modifier keys.

That's unfortunate; common behaviour of the zoom tool in paint
programs is click to zoom in, shift-click (or control-click or
alt-click) to zoom out, with the cursor having a +/- sign to indicate
the zoom direction based upon the modifier state. Whilst Tk lets you
determine the modifier state at the time of the click, you can't
determine it beforehand in order to reflect the state in the cursor.

This isn't critical; you can always provide help text in the status
bar or a tooltip to tell the user which modifier keys do what.

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

6

Michael,

Mouse thing seems a serious issue so I'll fork the thread.

Below I'll explain in detail other reasons why I prefer 3 button zooming
like in d.zoom. For gis.m zooming tool it would be good if it could
reproduce the behaviour. It doesn't matter with how many buttons/keys.

In gis.m currently one has to select _exactly_ the corner he wants
right at the very first click. And right on the second click it zooms
in. It is 99% sure I won't be satisfied with my first selection when
my area to be zoomed is not a simple shape. So I'll need to unzoom
(another tool) and zoom in back (another tool again). Maybe several
times. Bad.

Zooming out/in in d.zoom is very well designed, thoroughly thought. I
can refine the area selection within one zooming session. Once the
selection looks I confirm with middle. In case something went wrong
- unzoom with middle, redo selection. To quit press right. All within
one session. Efficient and elegant.

Please try zooming to a non-regular shape, some European countries
borders for instance. You'll see it is much easier with d.zoom.

Another solution would be if your current gis.m zoom tool had a
transparent "guidelines" following the cursor moves (sorry I can't think
of a better description, is it clear what I mean?), so it would be
possible to refine the zoom-in bounding box before performing the
actual zoom. What do you think? But still unzooming within the same
session will be missing. Using keyboard to change the +/- zoom
direction would do.

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

7

Michael,

Before gis.m stopped working for me due to recent tcl/tk 8.3
incompatibility, I have noted down following remaining issues.

CCing Glynn as some issues are display related.

1. Increase the width of main gis.m, a bit. Currently the properties of
a vector layer ("Display vector maps") doens't fit (few pixels) thus
the horizontal slider bar is there - actually no real need for it.

2. g.region zombies are gone. d.mon ones still bite. You asked me once
how to find them. Home-made zombie detector: ps -A -f | grep defunct.

3. When reducing the gis.m window size, the buttons in the bottom of the
window ("run" "clear" etc.) get hidden. When I enlarge the window back
they come back but a huge amount of space becomes wasted in the window.
Please do some resizing the window for and back to see what I mean.
Could the buttons be always left visible? And the window space not
wasted?

4. The "Digitize map" button doesn't work. In case of rasters something
pops up but dissapears in a flash. For vectors an error is issued:

child process exited abnormally
child process exited abnormally
    while executing
"exec -- d.mon start=x0 >@ stdout 2>@ stderr"
    ("eval" body line 1)
    invoked from within
"eval exec -- $cmd >@ stdout 2>@ stderr"
    (procedure "runcmd" line 5)
    invoked from within
"runcmd "d.mon start=x$xmon""
    invoked from within
"if ![catch {open "|d.mon -L" r} input] {
      while {[gets $input line] >= 0} {
              if {[regexp -nocase "$xmon.*not running" $line]} {
          run..."
    (procedure "GmVector::WorkOnVector" line 28)
    invoked from within
"GmVector::WorkOnVector $sel"
    ("vector" arm line 2)
    invoked from within
"switch $type {
        raster {
        term r.digit $sel
            return
        }
        vector {
      GmVector::WorkOnVector $sel
        }
   ..."
    (procedure "GmTree::vedit" line 16)
    invoked from within
"GmTree::vedit"
    ("uplevel" body line 1)
    invoked from within
"uplevel \#0 $cmd"
    (procedure "Button::_release" line 18)
    invoked from within
"Button::_release .mainframe.topf.tb1.bbox5.b0"
    (command bound to event)

And terminal reads:

using default visual which is TrueColor
ncolors: 16777216
Graphics driver [x0] started
Socket is already in use or not accepting connections.
Use d.mon to select a monitor
Problem selecting x0. Will try once more
Socket is already in use or not accepting connections.
Use d.mon to select a monitor

5. The current tool should be automatically de-selected when chossing
another tool. Currently it's not:

a) Use zoom, unzoom or pan tool.
b) Don't quit it.
c) Use query tool.
d) See how the tool you used in 1. still affects the display (moves,
resizes etc.)

6. gis.m will fail to display a raster of name identical to another in
different mapsets; and the "Map display" window will become broken after
that:

WARNING: 'cell/x' was found in more mapsets (also found in topo).
WARNING: 'cell/x' was found in more mapsets (also found in topo).
    while executing
"close $rt"
    (procedure "GmRaster::display" line 29)
    invoked from within
"GmRaster::display $node"
    ("raster" arm line 2)
    invoked from within
"switch $type {
        group {
            GmGroup::display $node
    }
    raster {
      GmRaster::display $node
    }
    labels {
      GmLabels::display $node
..."
    (procedure "GmTree::display_node" line 6)
    invoked from within
"GmTree::display_node $n"
    (procedure "GmGroup::display" line 14)
    invoked from within
"GmGroup::display "root""
    invoked from within
"if ![catch {open "|d.mon -L" r} input] {
    while {[gets $input line] >= 0} {
      if {[regexp "^gism.*not running" $line]} {
        runcmd "d.mon start=gis..."
    (procedure "MapCanvas::drawmap" line 22)
    invoked from within
"MapCanvas::drawmap 1"
    ("uplevel" body line 1)
    invoked from within
"uplevel \#0 $cmd"
    (procedure "Button::_release" line 18)
    invoked from within
"Button::_release .mapcan(1).mf.topf.tb0.bbox1.b0"
    (command bound to event)

7. The "Show data" button will not work for vectors outside the current
mapset, at least in case of DBF driver. This is due to you have specify
the path to a database for db.select implicitely at present:

a) I'm in mapset "topo".
b) To display data of a DBF table of a vector "cieki" in mapset "melio"
I have to use:

db.select cieki database='$GISDBASE/$LOCATION_NAME/melio/dbf/'

The way gis.m and d.m currently is doing it is:

db.select table=cieki@melio

Which leads to an error:

dbmi: Protocol error
dbmi: Protocol error

There is a thread open for this issue in the bugtracker. Markus says it
is not a bug. I'll close it as soon as I'm convinced. Currently I don't
quite understand why "db.select table=cieki@melio" should not work.
https://intevation.de/rt/webrt?serial_num=4083

On top of it, I'm not sure if using db.select for the purpose you are
using it is a good idea - the name of a datatable happens to be
different than the vector file name. The way "Show data" is now will
work for sure only for vectors created by Grass commands which
automatically create a table of the same name as the vector file. But
would not in case of multi layer vector files (e.g. v.clean output),
when the table names for each layer differ from the vector file name by
a _<number> suffix.

Does anyody know what else command could be used then instead of
db.select to avoid those problems?

8. The menu Xtns contains an active button "Add extensions here",
clicking which leads to an error for obvious reason - obvious for
somewhat experienced Grass user, newcomers might be puzzled. Could this
button be replaced with a plain text or removed?

9. Wish: make mouse wheel working in all the d.m/gis.m windows. This
issue was mentioned on the list before, few moths ago, and the
conclussion was it would be not doable for then. Any progress/chances
in this regard currently?

10. Zooming in is not working properly:

a) v.in.region output=frame
b) add the vector 'frame' to gis.m layer tree
c) g.region vect=frame
d) "Zoom to current region" in "Map display"
e) display
f) you should see the whole vector 'frame', but you don't

This reminds me of https://intevation.de/rt/webrt?serial_num=3613.
Still open.

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

8

Sorry for being rude, but could this discussion about new GRASS
feature development kept in dev list not both - user and dev lists?
Threads are in two places and out of sync.

tnx,
Maris.

9

I just posted a set of updates to gism2 to the cvs and my website.

These are mostly bug/annoyance fixes. Maciek has been helpful in identifying
these, so I will list them below. I want to freeze features so that gism can
be tested and remaining bugs eliminated.

IMPORTANT NOTE. There has been a recent change in the way the monitorcap
file is created that is causing problems in starting any command that
requires an xmon display from the GIS Manager. I think it is an error in the
makefile for XDRIVER, but I haven't messed with this.

Monitorcap is being created with a double set of xmon definitions.
Currently, you will need to edit this file to delete the second set of
definitions for xmon (x0-x6). Hopefully, this can be corrected.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

From: Maciek Sieczka <werchowyna@epf.pl>
Date: Tue, 21 Feb 2006 08:58:25 +0100
To: <michael.barton@asu.edu>
Cc: <grass5@grass.itc.it>, <glynn@gclements.plus.com>
Subject: Re: [GRASSLIST:10435] Re: [GRASS5] gis manager 2 rc3 - bug fixes and
updates

Michael,

Before gis.m stopped working for me due to recent tcl/tk 8.3
incompatibility, I have noted down following remaining issues.

CCing Glynn as some issues are display related.

1. Increase the width of main gis.m, a bit. Currently the properties of
a vector layer ("Display vector maps") doens't fit (few pixels) thus
the horizontal slider bar is there - actually no real need for it.

Done

2. g.region zombies are gone. d.mon ones still bite. You asked me once
how to find them. Home-made zombie detector: ps -A -f | grep defunct.

I don't know how to zap these for d.mon. Any suggestions?

3. When reducing the gis.m window size, the buttons in the bottom of the
window ("run" "clear" etc.) get hidden. When I enlarge the window back
they come back but a huge amount of space becomes wasted in the window.
Please do some resizing the window for and back to see what I mean.
Could the buttons be always left visible? And the window space not
wasted?

Fixed in last Friday's release. These no longer get hidden.

4. The "Digitize map" button doesn't work. In case of rasters something
pops up but dissapears in a flash. For vectors an error is issued:

child process exited abnormally
child process exited abnormally

snip snip

And terminal reads:

using default visual which is TrueColor
ncolors: 16777216
Graphics driver [x0] started
Socket is already in use or not accepting connections.
Use d.mon to select a monitor
Problem selecting x0. Will try once more
Socket is already in use or not accepting connections.
Use d.mon to select a monitor

This is fixed IF monitorcap is edited as I indicated above. The same problem
affects other commands that need to open an xmon. The GIS Manager will do
this automatically if monitorcap is changed.

5. The current tool should be automatically de-selected when chossing
another tool. Currently it's not:

a) Use zoom, unzoom or pan tool.
b) Don't quit it.
c) Use query tool.
d) See how the tool you used in 1. still affects the display (moves,
resizes etc.)

Implemented in this release. This is the only new feature introduced here.
Map display tools now behave like radiobuttons.

6. gis.m will fail to display a raster of name identical to another in
different mapsets; and the "Map display" window will become broken after
that:

WARNING: 'cell/x' was found in more mapsets (also found in topo).
WARNING: 'cell/x' was found in more mapsets (also found in topo).

Due to the information put out by d.rast I think. If the map is listed
properly for non-current mapsets (<file>@<mapset>) this probably won't
happen. But I haven't had a chance to look into this yet.

7. The "Show data" button will not work for vectors outside the current
mapset, at least in case of DBF driver. This is due to you have specify
the path to a database for db.select implicitely at present:

a) I'm in mapset "topo".
b) To display data of a DBF table of a vector "cieki" in mapset "melio"
I have to use:

db.select cieki database='$GISDBASE/$LOCATION_NAME/melio/dbf/'

The way gis.m and d.m currently is doing it is:

db.select table=cieki@melio

Which leads to an error:

dbmi: Protocol error
dbmi: Protocol error

There is a thread open for this issue in the bugtracker. Markus says it
is not a bug. I'll close it as soon as I'm convinced. Currently I don't
quite understand why "db.select table=cieki@melio" should not work.
https://intevation.de/rt/webrt?serial_num=4083

On top of it, I'm not sure if using db.select for the purpose you are
using it is a good idea - the name of a datatable happens to be
different than the vector file name. The way "Show data" is now will
work for sure only for vectors created by Grass commands which
automatically create a table of the same name as the vector file. But
would not in case of multi layer vector files (e.g. v.clean output),
when the table names for each layer differ from the vector file name by
a _<number> suffix.

Does anyody know what else command could be used then instead of
db.select to avoid those problems?

This now fixed for the GIS Manager. db.select will use the table connected
to the vector and specified in the layer setting, regardless of where it is
located or what it is named. It will get the relevant settings from
v.db.connect -g

8. The menu Xtns contains an active button "Add extensions here",
clicking which leads to an error for obvious reason - obvious for
somewhat experienced Grass user, newcomers might be puzzled. Could this
button be replaced with a plain text or removed?

This is for future expansion. I'm working with Benjamin Ducke on this and it
should be available soon. But we need to get the bugs out of this release
before moving ahead and implementing this.

9. Wish: make mouse wheel working in all the d.m/gis.m windows. This
issue was mentioned on the list before, few moths ago, and the
conclussion was it would be not doable for then. Any progress/chances
in this regard currently?

I don't know.

10. Zooming in is not working properly:

a) v.in.region output=frame
b) add the vector 'frame' to gis.m layer tree
c) g.region vect=frame
d) "Zoom to current region" in "Map display"
e) display
f) you should see the whole vector 'frame', but you don't

This reminds me of https://intevation.de/rt/webrt?serial_num=3613.
Still open.

Still working on this.

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko
najlepsze z nich!
http://katalog.panoramainternetu.pl/

10

Michael Barton wrote:

IMPORTANT NOTE. There has been a recent change in the way the monitorcap
file is created that is causing problems in starting any command that
requires an xmon display from the GIS Manager. I think it is an error in the
makefile for XDRIVER, but I haven't messed with this.

Monitorcap is being created with a double set of xmon definitions.
Currently, you will need to edit this file to delete the second set of
definitions for xmon (x0-x6). Hopefully, this can be corrected.

I cannot reproduce this. If you are getting a second set which doesn't
include x7, you have some out-of-date files in your build tree. Try
"make distclean" and "cvs update".

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

11

Just checked out gis.m for the first time since ~ day 1. It is looking
really good!

One question: (annoyance really, qgis is the same)
Why draw a box for zoom out? It doesn't make sense to me. Why not a
single click to trigger zoom-out? Does it control the amount you zoom
out? (I think that would be confusing too)

Matlab's display monitor window has a nice way of doing things- if you
are in zoom-in mode then the left button draws a box, and a right
button-click unzooms. Three or four unzooms in a row and the display
resets to the default (ie 'g.region rast=') region. If you are in
zoom-out mode the mouse buttons are reversed. Also a single click
instead of a drag & box does a 50% zoom under the cursor. This means
only the left mouse button is needed, but the right mouse button isn't
"dead", it provides optional functionality.

Another question:
Vector area boundaries look a bit blurry in the GUI. Sort of like when
you set d.vect linewidth=1 instead of width=0(off). ?

Hamish

12

Hamish,

Welcome back.

From: Hamish <hamish_nospam@yahoo.com>
Date: Thu, 2 Mar 2006 13:52:27 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass5@grass.itc.it>
Subject: gis.m

Just checked out gis.m for the first time since ~ day 1. It is looking
really good!

Thanks for the encouragement. I think it is a good direction and hope that
others do too. Just did a brief intro to GRASS at the end of a class today.
Not enough time to do it justice. But it is clear that the opening screen
has to be changed. New users (including exerienced GIS'ers) get glassy-eyed
and can give up before they start. It is very confusing (even if it makes
perfect underlying sense). I have an idea and may try to show something
soon.

One question: (annoyance really, qgis is the same)
Why draw a box for zoom out? It doesn't make sense to me. Why not a
single click to trigger zoom-out? Does it control the amount you zoom
out? (I think that would be confusing too)

Gotcha! It DOES do a single click to zoom out AND to zoom in. Single clicks
zoom in or out by 20%. The rectangle offers more control. Zoom in most
people are used to. Zoom out: the displayed map 'shrinks' to fit into the
zoom out rectangle.

Matlab's display monitor window has a nice way of doing things- if you
are in zoom-in mode then the left button draws a box, and a right
button-click unzooms. Three or four unzooms in a row and the display
resets to the default (ie 'g.region rast=') region. If you are in
zoom-out mode the mouse buttons are reversed. Also a single click
instead of a drag & box does a 50% zoom under the cursor. This means
only the left mouse button is needed, but the right mouse button isn't
"dead", it provides optional functionality.

I could put zoom and unzoom on the same button, but I don't have a way of
visually signaling to the user which mode he/she is in (like the button
icons). No good cursors in TclTk for this. I've gone through them all. The
radio button style gives good visual feedback and isn't REALLY that much
more effort is it?

Another question:
Vector area boundaries look a bit blurry in the GUI. Sort of like when
you set d.vect linewidth=1 instead of width=0(off). ?

Never noticed this, but can check.

BTW, did you see my shell script query?

Cheers
Michael

Hamish

__________________________________________
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