[GRASS5] Driver Update

[Markus Neteler]

On Thu, Apr 26, 2001 at 06:59:38PM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > So we have to watch out now for any module with backing store problems
> > (when using the latest Xdriver version). It can be simply fixed like
> > d.rast.edit. Another candidate is v.digit, there may be more modules
> > needing the R_stabilize() function.
> 
> I've done a quick scan of anything that might need changes (i.e. by
> looking for libraster.a in the build output).
> 
> The following are the ones which couldn't be quickly confirmed to be
> OK or fixed.
Glynn,

I have tested some modules:

> d.display
 -> not o.k., needs the R_stabilize()

> i.class
 -> raster is o.k., but the vector lines are not drawn unless you
  accept them.
  Test usage: use i.group to generate a group and a subgroup of at least
  two raster images (could be anything for this). Then start i.class,
  enter some file names as queried, then "define region"/"draw region" to
  draw vector lines as sample areas. Then drawing, the lines *should*
  be seen (the aren't unless you hit the right mouse button to complete).

> i.colors
  -> o.k.

> i.ortho.photo
  -> o.k.

> i.points
  -> o.k.

> i.points3
  -> o.k. for display
     Bug: If setting target reference point, nothing happens (not displayed,
          not accpeted). Note: i.points3 is *much* more convenient than
          i.points and it merges i.points and i.vpoints. We should get this
          working.

> i.vpoints
  -> raster o.k., vector maps not displayed at all (bug)
     bug: full screen not restored (frames not removed). Anyway, i.points3
     is my recommendation.

> v.area
 -> o.k.

> v.digit
 -> o.k.  (note: here the digitizing lines are shown which I am missing in
           i.class)

> d.fix.ortho   (src.contrib/SCS)
 -> the digitizing line is not shown yet (needs fix)

---------------------------------------
> r.weight
> r.water.fea	(src.contrib/CERL)
> paint/driver/preview
> paint/driver/preview2
 -> could not test, other volunteers wanted.


A related problem I found:
If you break a displaying module with CTRL-C, the monitor is blocked:
GRASS:~ > d.display
           # displaying something, then CTRL-C to kill due to above problems
GRASS:~ > Monitor <x0>: Premature EOF

GRASS:~ > d.erase
Monitor <x0>: Premature EOF

Same story with d.rast: if you CTRL-C it, the monitor is blocked.
In past this treatment was accepted and the monitor didn't die.
Closing is (of course) still possible. Could you change the treatment of
"Premature EOF" in the monitor to keep the monitor working?

If the user forgets to enter the right mouse button (to leave d.zoom or
another interactive display tool), the monitor is of course blocked as it
waits for the right mouse button. If you already start the next display
command like d.rast, nothing happens (as expected). If you *then* click
right mouse button, the monitor get's back to function and the message
occurs:
Monitor <x0>: Caught SIGPIPE
Then everything is o.k. What I want to say: Could you change the driver to
react in case of "Premature EOF" as when "Caught SIGPIPE" occurs? 

Hope this report helps,

 Markus

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'