Message-Id: <9104030012.AA09670@baby.bby.oz.au>
To: Chris Craig <craig@ics.com>
Cc: bug-at@ATHENA.MIT.EDU
Subject: Re: Anyone got a graph widget (Athena and/or Motif)? 
In-Reply-To: Your message of Tue, 02 Apr 91 11:19:36 -0500.
Date: Wed, 03 Apr 91 10:12:26 +1000
From: Gregory Bond <gnb@bby.oz.au>


Chris,

Thanks for your response.  I have a few comments and some other
suggestions.

I have had a number of "me too" requests following the original
article.  Are you happy for me to publicise the anon-ftp of this,
perhaps in the X FAQ postings?

Chris> I hope I don't sound like I'm saying "fix it yourself", too
Chris> much.  I just don't have the time to spend adding new features
Chris> anymore.  What I'm hoping to do is (1) fix obvious bugs that
Chris> people report, and (2) integrate changes that other people make
Chris> into the distribution.

Not a problem.  I am happy to contibute to the development (provided
the project for which I am investigating all of this actually goes
ahead - fairly likely) if there is some mechanism for distributing
updates and merging my changes back into the "official" source.
Perhaps using bug-at or another list for all "interested" parties.

Things I might do (if my boss lets me), in no particular order:

1) K&R-ize the source so we can make a shared library out of it.
   Would probably require some other hacking to make it sharable.

2) Add XtNshowYAxis and XtNshowXAxis resources similar to
   XtNshowY2Axis.  Some of our applications want R.H. axis but not
   L.H. axis (which makes more sense in a realtime situation - you are
   much more interested in the right hand, "recent" end of the graph,
   so the scale there is much easier).

3) Write a registration function to register the widgets with Wcl which
   I tend to use for prototyping.

4) Hack on the Imakefile to support shared libs, strcasecmp for older
   systems, etc.  General Sun port.

5) A new XYPlot-like widget along the lines of the one I previously
   mentioned, using the application structures to hold the data and a
   stride parameter. I am also considering having a type field, so the
   graph widget can plot integers, floats or doubles.  Given the type
   coercisons that have to be done for the stride parameter, this
   should be no problem.

6) Special handling of XtNticLabels along the lines I mentioned.

7) Add options for the axis ticks and labels to be inside the graph,
   not outside.  This maximises real estate usage.

8) Ability to specify rounding for the auto scaling in fairly arbitary
   ways (e.g. make all tics a multiple of x, etc).  I haven't done enough
   experimenting to find the exact limits of the existing scaling
   code... 

9) Ability to respond to "dump the graph in postscript" requests from
   other applications, perhaps by using ICCCM/WM communications.  This
   would allow the writing of a generalised graph annotator program.
   You select the graph with the cursor, the program sends the
   message, reads the postscript for the graph and then allows arrows,
   lines, text, etc to be scribbled over the top for printing or
   faxing or inclusion in documents etc.  Saves having generalised
   anotators built into every program.

Re the existing XYPlot and other widgets:

What were the reason behind the design decisions to make the xPoints
et al resources?  You can't specify anything useful in a resource
file, and the XtSetARgs/XtSetValues interface for programs is at best
clunky.  What I would consider for the replacement widget is a set of
member routines, e.g.
	typedef enum {AtInteger, AtFloat, AtDouble} AtDataType;
	AtXYPlotRegisterData(AtXYPlot w, XtPointer data, 
			     Cardinal stride, AtDataType type, 
			     Cardinal numpoints);
	AtXYPlotChangeLength(AtXYPlot w, Cardinal Numpoints);

and such.  This would seem to simplify the logic of the widget code,
especially the SetChanged routine and the redraw/refresh decisions.
(This is the approeach that Sundar's graph widget uses, and both the
widget and applications code seem to benefit).

Greg.