Stuart Jarvis A troll's eye view

The following is the full text of an email interview I conducted with the developers of the LabPlot and SciDAVis scientific graphing applications. This has formed the basis for my article on the applications on KDE Dot News.

1. First could you introduce yourself and explain your current role in your project(s)?

TB: My name is Tilman Benkert and I am 31 years old. I am co-founder, project manager, and developer in the SciDAVis project. I currently mainly work on the common code shared by LabPlot 2.x and SciDAVis.

SG: My name is Dr. Stefan Gerlach and i am 33 years old. I am the founder of the project LabPlot. Right now i am the maintainer of LabPlot 2 and work on bringing SciDAVis and LabPlot together.

KF: My name is Knut Franke, I’m 27 years old and I’m doing all sorts of things in the SciDAVis project – bugfixes, answering questions on the forum, creating not-quite-regular bugfix releases, writing documentation and working on the code for the next minor release. Apart from the work on our common code base, I’m currently not doing anything in the LabPlot project.

AS: My name is Alexander Semke and I’m 32 years old. I’m one of the developers.

2. Where do you live and what is your day job?

TB: I live in Stuttgart, Germany. I work as a software engineer.

SG: I live in Konstanz at the lake Bodensee and work as a scientist/lecturer and IT administrator in the department of theoretical physics at the University of Konstanz.

KF: I’m living near Cologne, and I’m currently working on my diploma thesis in theoretical physics.

AS: I live in Weinheim, Germany. I’m doing theoretical hadron physics at GSI (Gesellschaft für Schwerionenphysik) in Darmstadt, Germany.

3. Describe your project in a few words

TB: SciDAVis is an interactive cross-platform data analysis and visualization program based on the Qt framework. Its development is primarily aimed at high-quality plotting of scientific data, e.g., for publications or presentations. It strives to combines an intuitive, easy-to-use graphical user interface with powerful features such as scriptability and extensibility.

SG: LabPlot is a free data analysis and visualization program based on KDE and Qt. It tries to combine most of the features needed for advanced data analysis and easy creating high-quality plots under a user friendly GUI.

KF: SciDAVis is (to become) a simple and powerful cross-platform and free software environment for small to medium scale scientific data analysis and publication-quality visualisation. It is simple in contrast to completely script-driven tools like gnuplot or matplotlib and in contrast to (IMHO) badly designed GUI tools such as Origin and Grace, because you can perform most tasks intuitively by exploring the graphical user interface. It is powerful, because you can write Python scripts for automating tasks. As a scientific/engineering tool for small tasks, it demarcates itself from both business-oriented or general purpose analyis/plot tools like OpenOffice Calc and from environments for large-scale (and less GUI centered) statistical analysis such as ROOT and R. In practically all regards, we haven’t reached these grand goals yet, which is reflected by the pre-1.0 version number. Still, SciDAVis is already usable for many tasks.

4. When and how did your project start?

TB: SciDAVis started as a fork of QtiPlot in June 2007. Knut and me both where former QtiPlot developers before we started the SciDAVis project. Roger Gadiou, QtiPlot’s documentation writer at the time, also changed to SciDAVis when we announced the fork.

SG: I started the project LabPlot back in 2001 when i needed a good plotting program and couldn’t find any. In 2006 it was time to take the next step so i decided to really open up the project and started LabPlot 2.0 from scratch. Shortly after that we realized that a cooperation with SciDAVis would be a very good idea.

KF: SciDAVis started in June 2007 as a fork of QtiPlot – see question 9.

5. How did you get involved initially?

TB: I got involved in QtiPlot by contacting the main developer and asking whether he could use any help. About one year after joining the QtiPlot project, Knut and I decided to fork QtiPlot and founded the SciDAVis project.

SG: As the founder of LabPlot I am involved since the beginning 🙂
During my work on liborigin I learned about QtiPlot and the SciDAVis project.

KF: I got involved with QtiPlot when I was searching for a free data analysis tool for a lab course. QtiPlot was the best solution I could find, but lacked flexibility when it came to calculations, cross-referencing tables etc. So I hacked in support for column formulas and (later) scripting using Python, and some other details I was missing; fixed small bugs etc. Later Tilman and me founded the SciDAVis project, so there I was involved from the start.

AS: Last year I contacted Stefan and offered my help. There were no objections 🙂

6. Do you get paid to work on your project? If not, what is your motivation?

TB: No, I don’t get paid. My motivation is a mixture of enjoying programming in general, creating something useful, practicing my coding skills, realizing ideas, and being an active part of the free software community.

SG: No, i don’t get paid for working on LabPlot.
I really enjoy creating useful software and learn new things. To have some practical programming experience can be helpful in many ways. I also like to contribute (‘give something back’) to the free (software) world since i think this is the way it should be.

KF: I’m not getting paid for my work on SciDAVis. I’m doing it because I like designing software, because I’m using the application myself, because it is rewarding to see your work being useful to other people and because it’s a chance to give back something to the free software community that has provided me with many great tools.

AS: No, I don’t get paid.

7. Are you involved in any other free software projects? Have you been in the past?

TB: Other than reporting bugs, no. But I probably would if a day had at least 48 hours. 😉

SG: There are some minor projects i was involved or even started (liborigin, etc.), but besides of bug reports i mainly concentrate on working for LabPlot right now.

KF: No

AS: Labplot is my first FS-project. From time to time I see several things in the software I’m using which, as to my opinion, can be improved. May be I’ll extend my activities and contribute to some other projects in the near future if time will permit.

8. Why are your projects free software?

TB: It’s basically because of the four freedoms of the free software definition. The most important aspects of free software to me are that nobody restricts you how to use it, that you can modify it to fit your needs, and that it encourages people to contribute to its development.

SG: The main reason for releasing LabPlot as free software was the idea of working together without any limitations and to benefit from a growing free software community. And of course i would like to be part of this community that created software with a quality that proprietary application hardly ever reach.

KF: Being a fork of a GPL application, the question of licensing didn’t actually come up when starting SciDAVis. However, I wouldn’t want to change the license even if I could. As a free software project, you typically have fewer resources than a comparable commercial project, so whether it’s the best way of “getting things done” is probably arguable. It is a great way of getting the right things done, though; because you have no deadlines, marketing requirements or hierarchies that influence decisions. If you want something changed, you just do it (modulo some constructive discussions to prevent everyone from running in different directions). Compared with selling an application as a freelance developer, you get more contributions from other people, enabling you to create something larger than what you could possible do on your own; and you get free promotion by being included in Linux distributions, and by being featured on the dot. 😉

AS: Sure, ideological reasons are the most important. Furthermore, I’ve been using GNU/Linux and software for it for a quite long time (10 years or so). It is clear to me that this community can only survive, if a certain amount of developers participate actively in it. From the very beginning of my linux time I wanted to be a part of this community. But the time elapsed and nothing happened due to the lack of time. There always was a feeling of guilt – you can help, you do have the knowledge for it (I gathered programming experience during my university time and during my work on commercial Qt-based products as a freelancer) but you don’t contribute anything!
In the case of Labplot there also was a need for a stable and feature complete plotting software for linux for my own use. I ended up using xmgrace. Though fully sufficient for the needs of theoreticians, I was never happy and comfortable with this motif-based piece of software. Labplot, though not quit stable and also far from being perfect concerning the design of the user interface at that moment, had the biggest potential for me to become the software I was looking for. So, I joined the project.

9. What prompted the fork of SciDAVis from QtiPlot? Is future sharing of code likely?

TB: The reason for the fork where insuperable differences with Ion Vasilief, the founder and main developer of QtiPlot. Unfortunately, Ion reacted rather indignantly to the fork. Regardless of that, I think it’s rather unlikely that we share much code in the future. We are rewriting the core architecture of the application to improve extensibility and long term maintainability and thus deviate more and more from QtiPlot’s code. SciDAVis 0.2.0 already features an almost complete rewrite of the table and matrix code to make (among other things) the undo/redo functionality possible.

SG: Since QtiPlot is also a free software projects we might see some cooperation some day but this depends on the QtiPlot maintainers and the direction of this project.

KF: We had different ideas about many things, including design goals, management of community resources and the right way to make money from a free software project. Since we are, together with LabPlot, in the process of rewriting the core architecture, sharing of code probably won’t have a big future; although we have ported some patches in the past and QtiPlot in turn has included some code from us. While QtiPlot itself is moving pretty much in a different direction, some QtiPlot-related developments may be of interest to us, namely liborigin2 (an improved version of the liborigin project on SF.net) and libraries for exporting graphics from Qt to TeX and to EMF.

10. The SciDAVis and Labplot teams have announced a collaboration and sharing of mutually useful code. How did you become aware of each other and realise you could gain from collaboration?

TB: At the time we started SciDAVis, I already knew LabPlot. At that time, there was only version 1.x which is using Qt3. Since SciDAVis used Qt4 right from the start and LabPlot 1.x also didn’t have an architecture similar to what we wanted, it wasn’t very well suited for a collaboration at first. But some time after the LabPlot guys started the KDE4/Qt4-based rewrite (version 2.x), a SciDAVis user pointed out that we seem to pursue similar goals. So we contacted the labplot-devel mailing list, found out that he was right, and the collaboration started.

SG: At the time of starting LabPlot 2.0 from scratch we realized that SciDAVis is working on the same things. If i remember correctly it was a SciDAVis user who suggested that SciDAVis and LabPlot could work together since the goals of both projects are very similar.

KF: I’ve been aware of LabPlot for some time, but didn’t think about collaborating until a user pointed out that LabPlot was being rewritten for KDE4, asking us to consider merging our efforts.

11. What are your hopes for the collaboration? Why not just merge the projects?

TB: My hope is to bundle manpower and share as much code as possible to speed up the development. We also discussed merging the applications completely. But we (the SciDAVis developers) feel that Mac OS and Windows users would discouraged to use SciDAVis if they have to install KDE as a dependency.

SG: I hope that we can create a useful application with all features we can thing of.
The targeted audience of both projects is not so much different. We work on a common code base so only the GUI may look a little bit different. Ideally you can change the user interface at any time and try different things without being forced to use only one interface.
If it turns out that no one is using the KDE frontend anymore i would of course help to support the Qt frontend. But the main work definitely can be shared between both projects which may be available as libraries some day.

KF: As it stands, the collaboration is mainly about sharing backend code and plugins. The key point here is, where and to what extend can we make compromises without giving up too much of our respective goals? SciDAVis is expressly cross-platform, and the practical viability of KDE on Windows and Mac OS X remains to be proven. LabPlot on the other hand puts some emphasis on its integration with KDE. At the very least, we’d need an easy way of including a stable and not too large kdelibs package in our installer, keeping the application stand-alone. But this would still raise the issue of an additional dependency for people trying to build the application from source, particularly on Windows/Mac where it’s not just a matter of telling a package manager to install kdelibs. Considering that the ability to (easily) change it is one of the key benefits of free software, I’m sceptical about any complication of the build process. A somewhat smaller issue is that LabPlot and SciDAVis have currently somewhat different user interfaces in some areas, which would need to be merged to a compromise solution. Also, to be honest: Having participated in their creation, I’m somewhat attached to our name and logo. Possibly these obstacles could be overcome, but we’re currently baking the bread before we’re trying to slice it. 🙂 In any case, I’d definitely consider moving the common code into a library (as a new project), which could also be used for creating other (possibly special-purpose) interfaces and for stand-alone scripts.

AS: A big part of the code (primarily placed in the backend) will be used in both projects. So, the merging of both projects and the concentration of the man power on the common goals are already achieved. The hope is that this ongoing collaboration will last long time and will lead to the best plotting software the world have ever seen 🙂
Concerning the different approaches to the UI, just have a look at the current stable releases of both projects. SciDAVis, being a fork of QtiPlot, provides an Origin like way of doing plotting. Labplot is in a way a bit different from this approach. Both programs have their own user basis. This fact justifies the development of two Uis supporting different workflows.
There was already a discussion on the labplot-devel mailing list about the philosophy of the user interface. I think we’ll revive this discussion again soon after we’ve finished some important things in the backend. May be we’ll rethink the current designs and end up with a common interface. In this case we’ll still provide a KDE version of the program to better fit into the desktop.

12. Who is your target user?

TB: Typically scientists who want to present their data graphically.

SG: I would say mainly scientists. But any other who needs to work on data sets and want to create high quality plots is also welcome.

KF: In principle, anyone whose data analyis or plotting demands don’t fit into a classical spreadsheet application, but who still wants the comfort of an integrated graphical application with project management and interactive creation of data and plots. I guess the major features that separate us from a spreadsheet application require some background knowlegde in applied mathematics, so in that sense we’re mainly targeting scientists and engineers. But of course, anyone else who finds our application useful is welcome as well. 🙂

AS: Target users are people in the scientific field starving for a good plotting software for Linux.

13. Why did you choose to use Qt with or without KDE for your application?

SG: First i decided to take Qt over gtk because i never was happy with gtk and had some more experience with C++ (OO development) and Qt anyway. The main platform for LabPlot always was the free software desktop. KDE has some nice things for programmers and users that are not available in Qt (like standard dialogs, icons, communication between application, application configurations, etc.). Now that KDE4 is supported on Mac and even on Windows platforms we may be able to have these features available there too.

KF: Since SciDAVis started as a fork, the question didn’t really come up. Apart from that, a Qt application is easier to compile and distribute for Windows. Also, every additional library increases the overal complexity of a project, making it harder for new developers to join in, and introducing new possible points of friction. Compare question 11 on this point. I’m not yet convinced that KDE offers enough that would be relevant for us and that would compensate the disadvantages. For similar reasons, we also decided not to use the memory management facilities of the Boost libraries.

AS: Well, KDE is my favorite desktop. That’s it 🙂

14. Besides Qt and KDE, what other software do you build upon in your projects?

TB: We use the GNU Scientific Library for math operations, muParser and PyQt for scripting, QwtPlot3D for 3D plotting, and Qwt for 2D plotting. We are working on replacing Qwt, though, as it is focused on widgets rather than export quality and has a couple of limitations due to it’s backward compatibility to Qt3.

SG: I personally prefer to have as few as possible requirements for building and using LabPlot. On the other hand it should use libraries (like gsl, fftw, etc.) if available. Especially libraries for importing/exporting of different data types should be supported if available.

KF: GSL for special funtions and various analysis algorithms, Qwt for 2D plotting, QwtPlot3D for 3D plotting, Python for scripting and muParser as a light-weight expression evaluator for people who don’t need the additional features of Python. SIP and PyQt for the interface we export to Python scripts.

15. I suppose the transition from QtiPlot to SciDAVis was initially not too difficult – you had a basically working Qt4 application as a basis for your changes. How about the KDE3 to KDE4 transition for LabPlot – is it a case of porting the code or is a lot being rewritten?

TB: QtiPlot was still pretty freshly ported from Qt3 when we forked. Under the hood, we have been and will be replacing a lot of code completely to overcome limitations of the Qt3 heritage and the inflexible architecture.

SG: I first started to translate the KDE3 code to KDE4 but soon realized that it would be less work and produces cleaner code to start from scratch. Also there is some very old code in LabPlot 1 that needed a rewrite anyway. It was just time to rethink many basic things with my knowledge collected over the years.

KF: I would also say that SciDAVis is pretty stable; fixing bugs has been a major focus of our work. On the other hand, this means that we’ve had less resources left for implementing new features. The common development code (LabPlot 2.0 alpha) is neither particularly stable nor anywhere near feature-complete. It’s mainly about a clean design that will later make it easier for us (and others) to add new functionality.

AS: At the beginning we were just porting the software from KDE3/Qt3 to KDE4/Qt4. This porting was straight-forward. Many of the plotting routines could be taken over without adjusting to much. We also used this time to improve several widgets and dialogs. The KDE4 version of Labplot was regarded just as a port of the 1.6-version. But then the collaboration with Tilman and Knut started. There was a very vivid discussion on labplot-devel about the future plans and it became very soon clear that it is worth to start rewriting the application completely. The SciDAVis guys brought a lot of code into the labplot project (now placed in the backend), so we didn’t need to start from scratch.
During the discussions on the mailing list there was also some kind a agreement upon the general design of the user interface. Labplot 1.6 is pretty much dialog based. Say, if you want to change the properties of an object, you have to do this in the corresponding dialog. The problems with dialogs are apparent – they cover the important information and they make the user to click the “Ok” or “Apply” buttons. This problems can be solved by using dock widgets like in Koffice2. This is a thing that is surely worth to be considered further.
To make a long story short – Labplot2 will be more, then a simple port of the previous KDE3 application!

16. How mature and stable are the applications?

TB: The stable SciDAVis branch is maintained separately from the bleeding edge development code and new features are merged only slowly into the stable version to keep it stable and usable at all times.

SG: LabPlot 1.6 is stable since 2006 and only get bug fixes from time to time. I still get a lot of mails about LabPlot 1.6 so there seems to be a good user base.
LabPlot 2.0 alphas are just snapshots of the common code base. We currenty recommend to check out the code from SVN. I may release regular alpha versions after we implemented and tested new features that are important for end users.

KF: I would also say that SciDAVis is pretty stable; fixing bugs has been a major focus of our work. On the other hand, this means that we’ve had less resources left for implementing new features. The common development code (LabPlot 2.0 alpha) is neither particularly stable nor anywhere near feature-complete. It’s mainly about a clean design that will later make it easier for us (and others) to add new functionality.

AS: Labplot1.6 is quite usable but has some issues with stability and broken layouts at different places in the UI. I never worked with SciDAVis, so I can’t say much about it. The alpha version of Labplot2 is not usable at the moment.

17. Do you use SciDAVis or LabPlot in your day to day work?

TB: Currently, no, because I don’t need such an application in my day to day work.

SG: I have to admit that i use for gnuplot and Grace my daily work mostly because i use them for many years now and know their bugs. But this may change if LabPlot 2 will get stable.

KF: Yes, I’m using SciDAVis for examining results of calculations. I’ve also used matplotlib due to missing features in SciDAVis (and missing time to implement them…).

AS: In my work I rarely need a plotting software. But if I need one, this should be Labplot2 🙂 At the moment I’m using the combination of Mathematica and xmgrace. The first one is used to produce and analyze the actual data and to create quick plots. Then the data is exported to ASCII-files. The final version of the plots is created with xmgrace upon importing the files.

18. What operating system(s) do you use and why? Is there another type of scientific application lacking on this operating system?

TB: At home, I use Windows for gaming and Linux for about everything else. Why? Because I prefer Linux to Windows but most games I likek to play require Windows. On my last job, I developed mostly on Linux, my current job is Windows only.

SG: I only use Linux as desktop and server operating system. As the administrator in my department i know a lot about Linux and how to manage >200 computers in the scientific world.
I could think of a nice application for organizing scientific papers (there are some, but not what i would like to have). But i am quite happy with the available applications on Linux.

KF: I’m using GNU/Linux practically exclusively, because I like the modular and transparent unix design (and I don’t own a Mac), the way practically any part can be customized, and package managers with their reliable file tracking and automatic system updates. Also, I like the idea that – if I really want to – I can always dig down arbitrarily deep into any part of the system.

AS: GNU/Linux. I guess, the reasons why to use this system and the advantages of it are certainly clear to every reader of this site 🙂

19. Do you use KDE? What are KDE’s best apps?

TB: Yes. My favorite KDE apps are Kmail, Krusader, Amarok, K3B, Konsole, Okular, and Dragon Player.

SG: Yes. But mainly KDE 3. I use kontact for communicating and organizing my day to day work. But i also enjoy using applications like kdevelop, k3b or okular.

KF: Yes, I’m using KDE (version 4.3.1 at the time of writing). My favourite KDE apps are Kmail, Konqueror, Okular, Konsole and K3b. Though not really an application, I’d also like to mention the nifty Plasma desktop at this point. 🙂

AS: Yes! KDE is my primary desktop at work and at home. Konqueror, Kontact, Kate, Kile, Okular, Digikam, Konsole, Kdevelop, Amarok, Kopete, K3b are my favorite applications.

20. Is there a single market leading application that you aspire to exceed?

TB: We aspire to exceed all of them, of course. 😉

SG: There are some proprietary applications like Origin or SigmaPlot only for Windows platforms and also free applications like Grace only available on Unix platforms. So most of them are single-platform and lack many features and user convenience. That’s why we will exceed them all with the best platform-independent application ever (for this purpose) 🙂

KF: There are multiple applications with different degrees of overlap. Perhaps the most similar ones are Origin, Sigmaplot, Gnuplot and Grace. I’d not say that we’re trying to exceed any particular one, though; we’re trying to build a tool for a particular task. And we’re trying to find novel solutions for this, so in that sense there’s nothing 100% comparable.

AS: I cannot say what application is the world leading because I didn’t use all of them. I’m aware of Sigmaplot, Diadem, Origin, Igor Pro and Aabel. Those are commercial product that are not available for Linux and which I’ve already had a look on. All of them have some nice ideas but also different limitations, the biggest one being the non-availability on LInux. It is surely not wrong to look at different projects in order to get some inspiration. But in the case of SciDAVis/Labplot collaboration we also have a situation, where all of the developers are (were) users of such a plotting software. So, we have a lot of our own ideas and we have clear vision about how the software have to behave. To stay serious, I don’t want to say the final release of Labplot2 will exceed everything the world have seen before. But there certainly will be many features which the user, I hope, will appreciate and like.

21. What’s your ultimate vision for your project?

TB: Superior export quality to the full extent of Qt’s capabilities. A GUI supporting a work-flow which quickly leads you to the desired results with ease. Extensibility through Qt plugins and scripting to an extent that many users add their own features without our direct help.

SG: Having a flexible and versatile application for easily creating high quality plots and analyze all scientific data with a growing user community.

KF: I’d like to see SciDAVis become a flexible, powerful and easy to use data analysis and visualisation environment that is easy to extend by plugins and scripts. It should feature a very intuitive GUI, making it easy to get productive in no time. I think Kmail is a good example, because it is usable even for novice users, although it has some rather advanced features. The key challenge is to identify and streamline the common tasks without sacrificing flexibility. I’d also like to organize the core components as a library that can be used by special-purpose applications or scripts. Interfaces should be created for different scripting languages. Kross may be useful here, although I’m not sure yet how to (cleanly) export abstract interfaces in this framework. On the whole, I hope that many people will find our framework useful and contribute new plot types (ternary, waterfall, …), import/export filters (e.g. for OpenDocument spreadsheets), interfaces to various languages, data analysis plugins, documentation, translations, demo projects …

AS: I want to see SciDAVis/Labplot as the plotting application the linux users think first of, if they need such kind of software.

22. Do you have many other active contributors? What kinds of jobs are available for potential contributors and how can they get involved?

TB: SciDAVis benefits from several contributors who write documentation, prepare binary packages, provide translations, report bugs, and suggest features. Most needed are developers, though, as the application core requires a lot of work. Once we get the internals right and reach the polishing phase, we could also use icon designers and usability experts.
The best way to get involved is the scidavis-contributors mailing list.

SG: In LabPlot 1 we had a lot of contributer working on the translations. We definitely should merge this work with SciDAVis as soon as possible. We currently could use some help regarding the website of LabPlot and how we can create a common website for both projects. Also the documentation of LabPlot needs to be written someday.
Of course developer are always welcome, but also non-coders can send us bug-reports and ideas in various ways (bug tracker, mailing lists, etc.)

KF: At SciDAVis, we have a handfull of contributors working on the manual, on translations (Spanish, Brazilian Portuguese, Czech) and on Linux packages/Mac binaries. There are lots of different jobs available, starting from the usual bugfixing / feature implementation tasks, over participating in the development of the new codebase where we explore new territory in terms of architecture and user interface (so far for the coders), documentation writing, creating packages for Linux distributions that don’t have one (e.g. Ubuntu) and adding new translations or taking over unmaintained ones up to extending the web pages and/or creating wiki content. Apart from that, if you think you can make the application or the project better/prettier/friendlier in some other way, do let us know.

23. When will we see SciDAVis 0.3 and LabPlot 2.0?

TB: When will the 50 developers come along who help us finish them in no time? 😉

SG: At the moment i would say “when they are ready”.
I really can’t say when all the features are ready and stable for the end user. Hopefully we will have regular alpha releases with more an more stable features.

KF: “when they are ready” 😛 Seriously, this depends too much on the amount of time we can spare, and the amount of time being taken up by other tasks in the project.

AS: It’s very hard to say at the moment. Every of the main developers seem to be pretty busy a the moment. I hope I’ll have more time next month. Also, the development of the project will proceed more quickly upon finishing a couple of things in the backend, which are of conceptual especial importance (plotting framework, input-output filters etc.)

24. Thanks very much. Is there anything else you would like to add?

TB:Thanks for giving us the opportunity to present our two projects on the dot.

SG: I would like to thank all people working on SciDAVis and LabPlot. It is really nice to work with you on this project. Hopefully we can sort all things out soon and are able to deliver an application that was never available before 🙂
Maybe, with some promotion, we can have a large active community of users soon.

AS: I want to thank the KDE promotion team for the introduction of our projects to a wide amount of KDE users and to potentially new Labplot2 users.

© 2009 contributors