[Kst] Binding TODO

Barth Netterfield netterfield at astro.utoronto.ca
Sat Jan 14 21:03:28 CET 2006


On January 14, 2006 11:46 am, George Staikos wrote:
> On Saturday 14 January 2006 13:41, George Staikos wrote:
> > > // axis time interpretation
> > > void ...setAxisInterpretation(bool isIntrpreted, intpretation, display)
> > >         // interpretation is one of {JY, CTIME, JD, MJD, RJD, TAI}
> > >         // display is one of {JY, Y/M/D_H:M:S, D/M/Y_H:M:S, QT_TEXT,
> > > QT_LOCAL, JD, MJD, RJD, KDE_SHORT, KDE_LONG} bool ...isInterpreted()
> > > string ...Interpretation() // one of {JY, CTIME, JD, MJD, RJD, TAI}
> > > string ...Display() // one of {JY, Y/M/D_H:M:S, D/M/Y_H:M:S, QT_TEXT,
> > > QT_LOCAL, JD, MJD, RJD, KDE_SHORT, KDE_LONG}
>
>    This one is really ugly.  I think the bool redundant.  We should have a
> "none" argument instead.  I don't like the string types though.  At least,
> I don't like "Y/M/D_H:M:S" nor do I like "QT_*" and "KDE_*".  What do we
> really _want_ here?  Let's make a good interface on the script side and
> change Kst later.  Also maybe we should use an enumeration like in Line.

We want to either interpret according to one of the different methods, and 
display according to one of the different methods, or not interpret.

One thing we want, but don't (quite) have is a sticky default interpretation 
type which is set in the settings dialog (we have something there, but it 
doesn't behave correctly): planck would us TIA, BLAST would use ctime.
Then we would p.xaxis.interpret=true, in which case we would get the default 
interpretation.  If we wanted to change it, we would call:
p.xaxis.interpretation = ???
p.xaxis.display = ???


> > > void ...setMinorTicks(int minorTicks) // -1 means auto
> > > void ...minorTicks()
> > >
> > > void ...setMajorTicks(majorTicks)// majorTicks is one of {COARSE,
> > > DEFAULT, FINE, VERYFINE} string ...majorTicks()
>
>   These ones are slightly confusing to me.

minorTicks tells how many minor tick steps per major ticks.  Auto mean that it 
has 5 minor steps per major if the major step is 1Ex or 5Ex, and 4 minor 
steps if the major step is 2Ex. 

majorTicks defines ~how many major steps there are along the axis.  Since the 
major steps have to be 1Ex, 2Ex, or 5Ex, we can't define exactly how many 
there are, so we have 4 densities: coarse, default, fine, and very fine.

> > > bool ...defaultMajorGridColor()
> > > bool ...defaultMinorGridColor()
>
>    This is very inconsistent so I left it out.  You can query and set the
> grid colors, but can't set default.  I expect this will change in Kst2DPlot
> eventually so I would hate to bind it at this point.

OK

> > > void ...setScaleAuto()
> > > void ...setScaleAutoSpike()
> > > void ...setSetScaleAC(double range)
> > > void ...setScaleExpression(string min, string max)
> > > string ...getScaleMode() // one of (AUTO, AUTOSPIKE, AC, EXPRESSION)
> > > string ...getScaleMin() // current scale minumum (value or expression)
> > > string ...getScaleMax() // current scale maximum (value or expression)
>
>    I guess we want these to be slots:
>
> void scaleAuto([bool spikeInsensitive = false])
> void scaleAC() <-- need a better name.  suggestions?
> void scaleByExpression(string minExpression, string maxExpression)
> string minimumScaleExpression (read-only)
> string maximumScaleExpression (read-only)
>
>    The last question is, does "string scaleMode  (read-only)" make sense in
> terms of using it from the script side besides for display purposes?  Or
> should we use an enumeration?  See
> http://kst.kde.org/kstscript/docs/Line.html for an example.

I don't like the way this interface works either, but I don't know the correct 
way to do it.  There are a bunch of different scale modes, and they all 
require different requirements.  Hmmm....



More information about the Kst mailing list