[GRASS5] Driver Update

Markus Neteler neteler at geog.uni-hannover.de
Sat Apr 28 04:38:11 EDT 2001


On Fri, Apr 27, 2001 at 07:11:24PM +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.
> > 
> > I have tested some modules:
> > 
> > > d.display
> >  -> not o.k., needs the R_stabilize()
> 
> Any specific cases? d.display is quite a large program, which is why I
> didn't try to fix it there and then.
Sure, sorry. I loaded a raster map, it was only displayed when "wiping" the
monitor with another window. If you start it and load a raster map, it won't
appear.

> > > 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.
> 
> So this bug isn't related to R_stabilize()?
Yes, it will be something else (unfortunately). Volunteer wanted :-)
 
> > > 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.
> 
> So it doesn't need fixing?
It is not related to R_stabilize(). If we get i.points3 fixed, we can
remove i.points and i.vpoints from CVS and rename the much more convenient
i.points3 -> i.points. Would be another module structure simplification.


 
> > > d.fix.ortho   (src.contrib/SCS)
> >  -> the digitizing line is not shown yet (needs fix)
> 
> get_shift() has the drawing code commented out. Should this be
> re-enabled?
Probably yes. I'll try that.

[...]
> NB: The case where the client quits while waiting for a mouse click
> shouldn't have changed at all; the Get_location_with_* functions all
> have their own event loop, which doesn't return until a button is
> pressed. This isn't straightforward to change (it can be done, but
> it's potentially de-stabilising).
O.k. Once I was proposing a timeout for waiting for the right mouse button,
but the majority here disagreed. The only problem is that newbies (and non
english speakers) regularly ignore the mouse button description displayed
in xterm. Later they wonder why the monitor doesn't work any more...
However, I have no good solution for this. In other GUI-GIS you have
a button to be selected, therefore it's rather clear what's ongoing.

Markus

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



More information about the grass-dev mailing list