[GRASS5] Driver Update

[Glynn Clements]

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.

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

OK; this seems to be confined to draw_region().

> > 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()?

> > 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?

> > 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?

> 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?

This implies that some state is being retained between connections. 
This shouldn't happen, and I can't immediately see how it is
happening. I'll look into it.

> 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? 

It does; both cases "break" from the inner loop (get_command,
process_command), close the connection and wait for the next
connection.

Of course, this doesn't necessarily translate into the desired
behaviour; I'll certainly look into improving the robustness driver is
as robust as possible.

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

-- 
Glynn Clements <glynn.clements at virgin.net>

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