[GRASS5] Grass monitor library

[pcpa at conectiva.com.br]

Cópia Glynn Clements <glynn.clements at virgin.net>:

[snip]
> >   It clearly also needs some better error handling, bounds checking,
> and at
> > least for the code that use fifos, there are several places were it
> can block
> > forever.
> > 
> >   What is the current status of the monitors code at
> src/display/devices/?
> 
> It's now in a state where, once GRASS 5.0 is released, we can throw
> the whole thing in the bin and start again from scratch.
> 
> Seriously.

  I have some time constraints in the project where I am using grass (but
it will be open source, and I am trying to make it generic enough to allow
others to use the same codebase), else I would volunteer to write some of
the code. But basically, I think all monitors should share the same
library, i.e. only one SWITCHER.c file, and have several funcion pointers
in a structure, to call the proper interfaces. There should be some 
padronization to decide about LSB/MSB format when sending/receiving data.
And the library should export some sort of asynchronous interface, to avoid
needs for forking and poll´ing on different file descriptors...

> Look at the default "monitorcap" file:
> 
> 	#4105:driver/4105:Tektronix 4105: \
> 
> If the original architecture was designed with those sorts of
> limitations in mind, it's probably had its day.

  I think it should also have some api to add/remove new monitors in run time.
 
> Basically, src/display/devices and src/libes/raster need to go, with
> src/libes/display (and a fair number of programs) being re-implemented
> on top of better foundations.
> 
> But right now, the priority is to get 5.0.0 out of the door so that
> end-users have a single, more-or-less stable version instead of the
> moving target of whatever was in CVS at the time. This really isn't
> the time for another major change to the existing monitor
> architecture.

  Ok, Thanks for replying.

Paulo

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