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

[Brisset, Nicolas]

> SVN commit 706341 by netterfield:
> 
> Two new spec docs:
>   Fonts.pdf: description of how fonts behave in kst2
>   Layout mode.pdf: description of the UI in layout mode

Hey, I've just taken some time to read through those design documents
and they sure look really good !

I need to take more time to think about all that and post comments, but
for now I already have a couple of questions:
- 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 :-))
- 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 ?
- 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 ? 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.
- 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 ?). 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. I also wonder whether we shouldn't have two window
reference sizes (paper and screen) ?
- layout mode: although nothing is mentioned about that, I suppose (and
hope) that object grouping (with arbitray levels) will still be possible
? 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.
- 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... 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. 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... 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 ?)

Well, sorry for the long post. The summer break did not change me :-)
But I can't help it: I find those design discussions very exciting !

Nicolas