[GRASS5] Grass monitor library

GRASS GRASS developer
1

  Hi,

  I am implementing a front end to grass, where I am creating my own monitors,
so that I can layout better my application, can put function buttons around
the monitor(s) screen(s), etc.

  I believe there are some problems with the current library. Function names
are not very sugestive :-), it is very easy to get space name problems. But
the biggest problem is that it uses all around global variables. It should
have some sort of context, so that the library could manage several monitors
at once.

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

Thanks,
Paulo

2

pcpa@conectiva.com.br wrote:

  I am implementing a front end to grass, where I am creating my own monitors,
so that I can layout better my application, can put function buttons around
the monitor(s) screen(s), etc.

  I believe there are some problems with the current library. Function names
are not very sugestive :-), it is very easy to get space name problems. But
the biggest problem is that it uses all around global variables. It should
have some sort of context, so that the library could manage several monitors
at once.

  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.

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.

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.

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

3

Cópia Glynn Clements <glynn.clements@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@virgin.net>

4

pcpa@conectiva.com.br wrote:

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

You're using a significantly outdated version of GRASS. Removing
SWITCHER.c was one of the first of many changes which I made to the
monitor code.

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.

Not really much point at present; the clients have to run on the same
host as the monitor. Byte ordering might be an issue for a new
architecture.

And the library should export some sort of asynchronous interface, to avoid
needs for forking and poll´ing on different file descriptors...

Yep; the polling sucks, but at the time it was the simplest way to
implement both XDRIVER (which has to handle the connection to the X
server as well as the rasterlib connection) and the other drivers
(which only have the rasterlib connection) with a common code base.

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

5

Glynn Clements writes:
>
> pcpa@conectiva.com.br wrote:
>
> > I am implementing a front end to grass, where I am creating my own monitors,
> > so that I can layout better my application, can put function buttons around
> > the monitor(s) screen(s), etc.

This is probably a good place for me to jump in as I may want to do
some similar things.

A little background: I'm a researcher at USC's Information Sciences
Institute. Some of our current projects involve setting up a network
of seismic sensors that can detect vehicles driving by. I'm tasked
with creating a handheld visualization/interaction platform that can
do the following:

  * Display maps of the current area.

  * Display current vehicle position obtained in realtime from
    wireless GPS units in the vehicles.

  * Display sensor locations and status, including vehicle
          position/bearing estimates.

  * Calculate and display coverage predictions.

I've decided on the Compaq iPAQ, (206 MHz StrongArm 64MB RAM), running
Linux as my hardware platform, (along with wireless network and up to
1GB storage card).

I'm now investigating using GRASS for the basis for my software
implementation and I'm interested in suggestions/ideas from those who
have more experience with GRASS than I do, (I've only been fiddling
with it for about a week now).

I have already compiled GRASS for the iPAQ/Linux and it seems to be
running just fine. The only major thing I think I will have to do is
some GUI work to make things more stylus friendly, (large text-based
dialog boxes won't work too well in this environment). I'm thinking of
doing some Python work for this, (perhaps pygtk or wxWindows/GTK).

The other question/concern I have is how well GRASS will satisfy the
dynamic needs of my application. I'm thinking I'll use a database
interface to get my vehicle and sensor data into GRASS. I'd like to
have fairly regular updates of vehicle locations, (maybe 10 fps), as
well as enabling fairly rapid pan/zoom of the map. Do you think GRASS
is up the task?

Pardon my ignorance, as I am brand new to GRASS.

I'd be very interested in any comments or suggestions you have.

> It's now in a state where, once GRASS 5.0 is released, we can throw
> ...
> 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.

Looks like maybe I can start looking into a new architecture for
overhauling this stuff. Or might my effort be better spent just
writing GUI interfaces around the existing monitors?

-Carl

PS. If we get much discussion I suppose we can move to the grassGUI
mailing list. I didn't start there as it appears pretty dead right
now.

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
4350 N. Fairfax Dr. #770, Arlington VA 22203 703-812-3725