[Lazarus] Allowing multiple axes in TAChart

[Alexander Klenin]

2009/12/18 Albert Zuurbier <albert.zuurbier at gmail.com>:
> I am working on allowing multiple axes in TAChart (issue 0013832). I am
> working with the idea to have multiple x and multiple y axes for line
> series.

Sorry for the delay in my response -- the time I can spend on Lazarus
is very limited lately.
Still, I have finally made some progress on the issue, although much
is still left to be done.

As I said on the forum, first the source-element-to-graph-point
translation must be abstracted out.
This is done in r23207 and r23211.

Then, the transformation itself should be introduced.
This is relatively large change, done in r23214, r23217 and r23241.
(BTW, thanks for fixing my stupid thinko, Paul).

It also includes (optional) binding of series to axes,
although in a manner different from your patch.
(In the future, please post patches as unified diffs in the future.
Simple diffs are rather hard to read.)

> At this moment the axes do not have minimum and maximum values (I've
> submitted issue 0015371). As far as I know, the minimum and maximum values
> moved to the chart (extent) recently. The axes have an offset and scale. The
> offset and scale however are quite difficult to use.

It is not hard to simply create Min and Max properties instead of
Scale and Offset,
but I do not think using them is really easier.
Calculating said properties automatically is indeed a good thing for
some applications, but not for others.
Also do not forget e.g. logarithmic scale, which is often requested by users,
(it is already implemented in r23217, but the implementation will
likely change).

The solution is to create multiple Transformation types -- first step
in that direction is
already done by extracting Transformation into a separate class.
The second step, however, has met a roadblock
Currently, ObjectInspector seems to display only fields from the
base class for class property even if it is actually assigned an object of some
descendant class.
(As opposed to component editor, whose properties are changed dynamically).

So, I have a few choices:
1) Punt, and stuff everything into one giant Transformation class.
  Good: Trivial to implement.
  Bad: Ugly and inefficient.
2) Implement each Transformation as a separate component,
  similar to ChartSources.
  Good: Rather simple to implement, clean design.
    Transformations may be shared among several axises and even charts.
  Bad: Component palette and form designer pollution.
    Slightly harder for novice to find.
    Some transformations (like those auto-scaling ones you proposed)
    should not be shared, and sharing them may lead to non-obvious bugs.
3) Implement each Transformation as a separate class,
  with the custom property editor.
  Good: Clean and efficient. May have intuitive interface, if designed properly.
  Bad: Hardest to implement (but the problem is in the editor, not in
Transformation itself).
    Transformations may not be shared among several axises.

For the meantime, I did (1) get something working fast.
My preferred solution is (3), but that will take a while to implement properly.

So if anyone has other ideas, arguments for/against the choices above,
or, better yet, property editor patches -- please share ;-)

>Are my ideas correct and should the scaling be distributed between axis and chart?
Yes, it should, since not all scaling is linear.

>Do we seek compatibility with the Delphi chart component?
No, we do not, except at "vaguely similar" level.
It is still a good thing to check Delphi implementation
for overall concepts.

-- 
Alexander S. Klenin