On Tue, Jun 12, 2012 at 5:40 PM, Nicolas Brisset <span dir="ltr"><<a href="mailto:nicolas.brisset@free.fr" target="_blank">nicolas.brisset@free.fr</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

What is your next target? The point scaling issues? The ASCII issue with empty columns?<br></blockquote><div><br></div><div>ASCII issue should now be fixed.  I would like to rework data points and line widths.</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Or should we start trying to implement ASCII date/time as per <a href="https://bugs.kde.org/show_bug.cgi?id=243684" target="_blank">https://bugs.kde.org/show_bug.cgi?id=243684</a>, which is my personal favorite new feature for the next version, hopefully?<br>

</blockquote><div><br></div><div>That will be fun and useful, but requires a well thought through plan - which we have started.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I have been thinking a bit after you implemented EXCEL time and I believe we have to find a way to represent dates as doubles (maybe the current approach is jsut fine, I just don't know the details)</blockquote><div>
<br></div><div>They are.  There are several ways with different offsets though: ctime, JD, Excel.  The scaling doesn't matter, but the offset does.  The further you are from the epoch/zero of the standard, the lower the resolution you get.  So you want to use ctime if you can get away with it.   kst's implementation of ctime times is happy to go negative I think, so it will probably always be either the best or an acceptable choice.  So I think that we will just output time vectors in ctime.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and then get the ASCII datasource to interpret the strings as dates and produce the right values.<br>

We should also probably add a "TimeType" enum property to vectors to say if they are time vectors, and how they should be interpreted. We could then set it from the wizard, the plot axis properties, or the vector dialog. If it is set on a vector used for X axis, we could then switch on time interpretation automatically.<br>


How does that sound (it's only a rough online to get the discussion started)?</blockquote><div><br></div><div>Sounds correct.  The TimeType enum would just set the defaults when creating a plot.  You will still be able to change them, like you can now.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888">
Nicolas<br>
</font></span><div><div>_______________________________________________<br>
Kst mailing list<br>
<a href="mailto:Kst@kde.org" target="_blank">Kst@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kst" target="_blank">https://mail.kde.org/mailman/listinfo/kst</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse;color:rgb(136,136,136)">C. Barth Netterfield<br>University of Toronto<br>

<a href="tel:416-845-0946" value="+14168450946" target="_blank">416-845-0946</a></span><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse;color:rgb(136,136,136)"><br></span></div><br>