[Kst] 2.0.3 RC "QA" results

[Nicolas Brisset]

Hi,

so I've played around with a lot of features. The version is today's svn. Here are some observations. It looks good on the whole, and I wouldn't mind releasing as is, apart maybe from the crash I listed first, but it may be ditro-specific. 

If one or the other issue can be fixed in a few minutes, we can also do it quickly before release (but I won't have time). Otherwise we can do a 2.0.4 soon after 2.0.3 before starting more complicated things for 2.1.0... I'll let Barth decide :-)
In any case I've listed all my observations here so that I don't forget them later... Sorry that's it's become a bit long, but I tested quite a lot of stuff.

- the polynomial interpolation plugin crashes!!! Message: symbol lookup error: /usr/lib/libgsl.so.0: undefined symbol: cblas_dasum. I have gsl 1.12... The gaussian fit also crashes with a similar message (cblas_dnrm2). This is with stock openSUSE rpms, does it also happen on other systems?
- when in layout mode, there is an offset between the image you drag around and the location at which the plot is anchored when you release the mouse button. This really gets on the nerves!
- in layout mode, rotated plots are shown normal during drag (Peter already mentioned this, but I don't know whether it's hard to fix it or if he just forgot)
- using the edit multiple mode on curves, you can't set point properties correctly: the drop down to point types is not showing anything useful (white on white...) and Density is disabled even when you click "Show points". It works in "edit single" mode. If it's easy to fix, that would be nice... "Show lines" works well, so I guess it's not too hard.
- legend font sizes seem to default to 0 points (and are shown with a tiny font here, which does not even seem to obey the minimum font size I set in the settings)
- the change data file tool does not remember the last new file used
- when you add a curve based on an equation to the first plot, all plots on the page are rearranged and the first one becomes the last one. Very disturbing! (This happens with "Automatic layout" checked, but automatic layout does not do that if called from the RMB!)
- I don't like the fact that plugins create 2 slave vectors. That's a point we've alredy started to discuss => I'll come back to it post 2.0.3
- legend items should be unique, they are not. To reproduce: plot CStk from the TWIN1xxx sample, then use the change data file tool to plot the same from TWIN2: the legend has two identical entries. In that particular case the name could stay in the left label as it is common, and we'd need a hint at the datasource or a way to recognize which curve is which (the C1/C2 id?).
- if you generate a scalar from another scalar (you can, using the Generate option even though it's a bit clumsy without the scalar selector) it does not get updated. If you create a label from it, the label obviously does not update - which is a use case we discussed recently... The name of the scalar is also not very elegant ("fixme: set _slaveName!")
- the undo/redo system is broken to the point where I fear using it (it crashes pretty easily). Even Word does it much better (though that's about all it does well!)
- when showing only part of the points (density < all), the intervals between points look weird/very uneven
- if you do an equation like [CStk (V2)]-[offset (X83)] where offset is a generated salar set to some value (e.g. 10), when you change the value of offset from the data manager the curve does not update. Double-click the equation and hit OK => the update comes. 
- when plotting XY plots and PSDs from the TWIN1xxx sample on CStk, PStk, RStk, YPdl the plots with PSDs don't get a log X-axis by default. Maybe they should? But worse is the fact that when you set the X axis to log, you get strange curves with a first X point around 1e-281. And the best part: when you plot all points, the X-axis range changes. I'm confused...

Well, even though 2.0.3 looks like a pretty nice and stable release (better than previous ones in the 2.0 series in any case), it looks like there are still some things we can improve around the edges. Of course, most of the points above are a bit hidden and don't prevent from working efficiently with kst. But if it's all about ploish, then we can/should do some more.
And I haven't yet started telling you all the ideas I have for the longer term... We definitely need more developers!

Nicolas