[Kst] branches/work/kst/portto4/kst/devel-docs/Kst2Specs

[Barth Netterfield]

On Thursday 30 August 2007 7:02:26 am Brisset, Nicolas wrote:
> - could the concept of "label region" between plot rect and plot outer
> box be extended one level up so that the top-level view also has a
> "border" (I know, I keep on asking the same question under more or less
> hidden forms: for the less alert readers, this is indeed another
> shameless attempt at reviving bug #109430
> http://bugs.kde.org/show_bug.cgi?id=109430 :-))

I haven't started thinging about automatic layouts and gridding in detail yet.  
But borders and anchored objects are two things I agree that we want.

> - what happens on resize if a view object (say, a box) is drawn over two
> plots, or worse in the label region but overlapping the plot rect ?

I should define that better.  I was planning on automatic parenting.  The 
object is considered the child of the smallest object which contains it, and 
is then resized with the parent.  So: If a box overlaps two plots, the box 
will be the child of a larger object (eg, the TLV, or a layout object), and 
will resize with the larger object (so the corners won't stay fixed to the 
data).

An alternative is to have each point the child of the innermost object which 
contains it, but that seems really hard to define cleanly.

> - page 2 of the "Plot geometry" doc: wow, that looks complicated! I need
> to think about it a bit more, but my first impression is that unless
> plots are grouped (which needs to be defined more accurately, but
> something along the lines of shift+click to select multiple plots in
> layout mode + RMB->"Group" as in kst 1) we may want to let each handle
> their plot rect and label region. In fact, what confuses me a bit here
> is why label regions would need to have different sizes: should the font
> size be shrinked to fit in the available space when there is too much
> text (label region size gets computed first, then font size) or it is
> the font size that determines the size of the label region ? 
Imagine the Y axis of one plot goes from 779000 to 779100 and the next one 
goes from 1.0 to 1.3.  The lable region of the first plot will need to be 
much wider than the second.  For things to look right: the fonts should be 
same, and the axis should be alligned.  Hence the behavior described. This is  
what kst1.x did.  It actually works pretty well, but I agree, it is 
complicated to make it look simple :-)

> I think we 
> should make sure that in the "normal" case (no plot-specific font size
> requested by the user and all labels fitting in one line with the
> default font size) all plots look good: plot rects aligned, same font
> size everywhere, and that without a performance penalty.

That is what this does.

> - regarding font sizes: I welcome the change corresponding to footnote
> 1, because the current behavior often yields some strange effects with
> slightly varying font sizes. I think it is good to base the font size on
> the window size (but why widht+height and not just height ?). 

This way
Short wide windows and tall thin windows will have the same font size.
Short wide windows will have smaller fonts that tall wide windows.

> But if I 
> understand it correctly the TLV is the top-level view, which is what
> we'd call "window" (the canvas size of a given tab). If that is so,
> wouldn't it be better to define a "reference *page* size" and "reference
> font size" ? I find the mapping window->paper page more natural than
> plot->paper page. 

Whoops!  That is what I ment.  I'll fix the typo.

> I also wonder whether we shouldn't have two window 
> reference sizes (paper and screen) ?

I don't think so... Word processors etc do fine with just 1.  If it turns out 
to work poorly w/ 1, we can change it.

> - layout mode: although nothing is mentioned about that, I suppose (and
> hope) that object grouping (with arbitray levels) will still be possible?

I think so.  I haven't started thinking about it.  Now is a good time to tell 
me what sorts of things you want to be able to do.

> And on a sidenote, couldn't we leverage the flake architecture here 
> (which may be part of koffice only, not kdelibs) ? This would avoid code
> duplication and guarantee consistency. Note that this is a naive (i.e.
> probably stupd) question, as I'm not familiar with it.

Right now we are QT only.

> - datasource changes: I like them, though I don't understand everything.
> Hopefully there will be reasonable defaults in the base classes, so that
> people who want to quickly write a new datasource don't get
> overwhelmed... 

Adam and I are in mild disagreement here.  Adam wants to make heavy use of 
pure virtuals in base class to enforce implementation of the goodies, and I 
want to have generic defaults to make life easier.  We'll probably end up 
somewhere in between.

> One thing I'd like to fully understand is how time 
> should/will be handled. User-friendly time-based access (a la amarok) is
> a feature that could be very nice, but it is also tricky with a very
> general plotting program like kst where time is just a vector among
> others.

That is why datasources will now provide a time vector, which can be 
configured.  I am not totally confident it will be easy in the end, but we 
should try.  Ideas are welcome here.

> And another point I wonder about is how to handle asynchronous 
> datasources easily (i.e. when vectors may have different sample rates).

> I once made a proposal I called "buddy vector": I have to dig for it in
> my archives and see whether that could make sense... 

Interesting... I can see how that would be useful.  I'll talk to the Planck 
guys and see if they could still use such a concept.

> Yes, datasources 
> can become complicated if we want to solve all issues nicely (didn't we
> also have a tough/unresolved issue with auto-updates of labels from
> datasource metadata on file change ?)

The update system is still to be designed.  Its not going to be easy though!!!