staikos at kde.org
Fri Dec 9 18:38:46 CET 2005
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:
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
l = new Legend(p);
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;
-> 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
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.
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the Kst