[Kst] extragear/graphics/kst/devel-docs

[George Staikos]

On Friday 09 December 2005 11:54, Barth Netterfield wrote:
> SVN commit 487163 by netterfield:
>
> A rebuttal :-)

  I see it more as supporting material. :-)  I agree, we need to keep the 
functionality, and what it does from a user perspective is great.  The 
problem is that it's unmaintainable and almost incomprehensible to work on at 
this point.  I tried to figure out what things to bind to the script language 
by looking at the header file and I came up with only one thing: tied zoom.  
This is not good.  All the axis stuff is such a mess that it's very difficult 
to figure out the proper way to manipulate it, for instance.

  Regarding the axis bindings, I'm thinking that the best approach is to have 
a separate object in KstScript which contains axis parameters:

plot.xAxis.label
plot.xAxis.log
plot.xAxis.min
plot.xAxis.max
etc

  To really see the problem, try to write a small application that links to 
kst2dplot as-is, creates a plot with customized axes, etc, and zooms in on a 
specific region in the plot.  Make sure that you write code that won't break 
when something in Kst2dPlot changes internally.

In KstScript I imagine it would look like this:
p = new Plot
p.curves.append(c);
l = new Legend(p);
l.curves.append(c);

y = p.yAxis;
y.log = true;
y.min = 0.01;
y.max = 1;
y.label.text = "Y axis label";

x = p.xAxis;
x.label.text = "X axis label";
x.time = true;
x.timeUnits = "hours";
x.min = 42;
x.max = 78;

p.setAxes(x, y);

   -> Tied plots would automatically be updated
   -> Scale is automatically saved
   -> Out of range truncates, and in the worst case throws an exception which 
users will probably ignore anyway.

There's no reason why this should be so complicated, and no reason there 
should be 16 public methods and 2 public statics related to setting the scale 
of a plot, none documented.  Notice that the JS object, which is conceptually 
equivalent to the C++ one, minus the UI stuff (which probably should be 
pulled out anyway), has only one function and three properties unique to it: 
setAxes, xAxis, yAxis, and curves.  It would take me much much longer to 
figure out how to write this in C++.

  Funny enough, I might have implemented this already but I'm not even sure 
how to do it sanely and be sure it doesn't break when kst2dplot is next 
changed.  Adding more methods to kst2dplot to use from KstScript is 
definitely not the right approach.

  In theory, these bindings could have been automatically generated.  That's 
what KJSEmbed does.  In practice, the interfaces are so far from what they 
need to be, we never could do that.  The only things that are close to 
bindable right now are some of the data objects and the non-2dplot view 
objects.

  Anyway, that's just one small example of the problems.

  One that's more worrisome from a user perspective is how the objects change 
state.  I can see some interesting effects in the future when a script is 
running while someone hits print.  changeToMonochrome() is called, the plot 
completely changes state, the script references properties, then 
undoChangeToMonochrome() is called and the script sets properties back.  We 
end up with one broken looking plot.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/