[Kst] Collaboration between kst and scidavis/labplot
Alexander.Semke at web.de
Tue Apr 12 22:52:19 CEST 2011
first of all, sorry for the long post comming. But I hope, it'll be worth
A couple of days ago Nicolas wanted to initiate a discussion on the scidavis
mailing list concerning the potential collaboration betweet scidavis and kst.
As you may know, there is already a collaboration between scidavis and
labplot. The current development of both projects proceeds in the labplot-svn-
repository. Since there was no "official" reply on the scidavis mailing list,
I, as one of the labplot developerss, want to describe my opinion on this
The number of active developers in scidavis/labplot collaboration is very
small and the progress is very slow. To put it in other words - we've got
already KDE 4.6 and there is still no stable and usable KDE4-version of
labplot. A possible collaboration with kst is very welcome.
Concerning the GUI design, supported workflows and the current code basis, kst
and labplot are very different. Nevertheless, I think there are many places
where we can collaborate.
At the beginning of the scidavis/labplot collaboration there were many very
vivid discussions about our common plans. A part of those discussions was
summarized on the labplot-wiki and on the scidavis homepage . The
information is a bit outdated by now. So, let me briefly summarize the main
1. we want to provide an interactive plot software, where each element on the
worksheet (working area) can be selected and easily edited, similar in
worklfow to vector graphics software. As to me, the software that comes most
closely to this goal and that is available for linux is veuz .
2. all the objects available in the project are accessible via the "project
explorer". The project explorer provides a tree-like view of the project
structure. The internal data is stored in a data model (Qt's model/view
3. the data for the plots comes from the different data sources, where one of
them is the spreadsheet. The spreadsheet provides the "origin-like" way of
working with the data. The spreasheet-less workflow, similar to kst, is also
supported. I think the concept of data sources, that is documented on the wiki
and partially implemented in the code is in close relation to what kst is
4. Undo/redo functionality throughout the software, scripting etc.
The current labplot code is by far not so complete and stable as the current
kst code and, may be, it's not easy to convince you to have a look at out
code. So, I'll try to formulate the next centencies very carefully :-)
Points, where kst can benefit from scidavis/labplot are the model/view-part of
the software together with the project explorer, that gives an overview/access
over/to the objects in the project. There is a "Data Manager" in kst2, which I
think is similar in goals, but limited to the data sources only.
kst can benefit from a plotting framework, supporting a high degree of
interaction and the organisation of the GUI with the help of dockwidgets
(without to much dialogs making the software clumsy in use).
Furthermore, the spreadsheet-view (and the matrix-view) as a source for the
data or just as a view for the imported data can valorize kst.
On the other hand, scidavis/labplot can heavily benefit from kst's data
sources, many different filters and the experience of handling and presenting
big data sets.
Our current code is placed in labplot-svn. The part of the code, which
presently needs the most attention is placed in the directory "backend". There
are two frontends - the pure Qt-frontend (scidavis) and the KDE-frontend
(labplot). Presently, the later one makes usage of more features implemented
in the backend. The KDE-GUI is kind of limited at the moment, since we didn't
found an easy and clean way to handle the many QActions/KActions for the Qt
and KDE frontends, respectively. E.g. all the context menu in the spreadsheet
are currently not active (the context menus and, consequently, the spreadsheet
features are partially accessible in the qtfrontend). The implementation of
the toolbars is also next to nothing. There is a lot of half-ready code
available and I hope I can finish many things soon, so that the software
becomes more usable.
What's your opinion? I hope to see/read your feedback on these topics here.
More information about the Kst