[GRASS5] Grass 5.0.0 TclTk 8.4 on Jaguar

[Glynn Clements]

Jeshua Lacock wrote:

> D. Using the X0 (X1, etc.) monitor still uses the non native XFree 
> library to display. I plan on eventually eliminating XFree altogether - 
> any comments and ideas are appreciated.

This was done for Windows by using a library which emulates the X11
calls. Mapping the various graphics "commands" to API calls was the
simple part. The biggest problems were:

1. The way in which the monitor puts itself into the background. The
technique which is used in src/display/devices/lib/main.c relies upon
the fact that child process will be able to use the window which was
created by the parent in Graph_Set(). This works for X due to its
client-server architecture, but it won't work for other platforms.

The fix used for Windows was to modify mon.start so that:

a) the monitor is spawn()ed as a child process, rather than exec()ed
in the current process, and

b) the monitor is passed the "-" switch, which prevents it from
fork()ing.

The downside is that the first attempt to select the monitor with
mon.select fails (as the monitor hasn't started listen()ing for
connections at that point), producing a warning message. The second
attempt normally succeeds, but it could fail if the monitor's startup
takes too long.

A cleaner solution would involve the parent fork()ing, the child
initialising the GUI aspects (i.e. Graph_Set()), and using e.g. 
semaphores so that the parent can exit at the point that the child
finishes the initialisation.

2. The monitor needs to interleave input from the client with GUI
events. On X, both forms of input are sockets, so it can use select(). 
Ideally, you will need to find some way of waiting until either input
is available on the socket, or an event is received. Otherwise you
would need to poll, which requires some care to avoid consuming 100%
CPU.

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