Left in for historical reference. Please see the SourceForge Tickets system for current plans and tasks.
Q_DECLARE_INTERFACE. The plugins may call the interface of core classes (e.g., Project) directly while core classes may not call any other functions of the modules other than those defined in
It is very important that SciDAVis remains maintainable in the long run. This is done by separating the application's functionality into modules that interact though a well defined interface. Most of the current features should remain part of the main executable, but use interfaces similar or identical to those used by plugins. This interface is defined in the ``core'' classes. Thus, if a developer works on one module (e.g., ``table''), he only needs to know the module code as well as the ``core'' code. Monster classes that depend on almost every other class such as ApplicationWindow in the 0.1.x code are to be strictly avoided. Additionally, data should be passed as pointers, not strings that need to be parsed (such as table_name + ``_'' + column_name). If components (aspects) are saved, they can be unambiguously identified by their path in the aspect hierarchy. This also reduces the restrictions on object/column/table names.
The split-up into modules also serves a second purpose: Making SciDAVis easier to extend. Ultimately, it should be rather easy for any C++ programmer to add a plugin using the plugin interface that all the existing modules such as ``table'' and ``matrix'' implement. Additionally, the functionality will be extensible using the scripting framework. For example, ideally it should be possible to implement new plot or marker types without modifying existing classes. The scripting system is a combination of extending and embedding the scripting language. That means the interpreter is embedded into SciDAVis and the scripting language is extended by functions to access objects within SciDAVis. The Python bindings are generated using SIP. The scripting system is planned to be language independent with Python as a standard implementation. Python is a good candidate for this as it is widely used and offers very good mathematical libraries that can be used from within SciDAVis. But other scripting languages such as Ruby should also be supported by SciDAVis, provided someone maintains the Ruby bindings. For stability reasons, not the whole SciDAVis API should be made accessible by the scripting system but only the ``public API'' (see aspect framework description in the doxygen documentation in /trunk).
The hardest part of the modularization is to keep the features of version 0.1.x while internally almost everything is restructured.
Current status (estimated percentage of completion, 0
The most noticeable features planned for the user interface are a full-featured multi-level undo/redo framework (based on QUndoCommand), easy access to options/controls previously placed in modal dialogs in the control tabs, and support for non-contiguous selections (see: QAbstractItemView::ExtendedSelection). How the undo/redo functionality works is defined in the aspect framework. The control tabs are already implemented for Table and Matrix. They can be shown/hidden using only one mouse click and typically process all selected cells.
Status: Control tabs in Table and Matrix are about 80% finished. Whether control tabs are useful for other parts is not completely decided. The undo/redo framework goes hand in hand with the aspect framework. So far only the core class as well as Table and Matrix have undo commands.
We plan to switch file format to a completely XML-based one. This allows for writing a robust parser based on Qt's XML support, more precisely QXmlStreamReader and QXmlStreamWriter. These are very fast and easy to use. Legacy support for the old format could be outsourced into a plugin.
Status: As good as finished for Table and Matrix. Project and Folder are pretty far as well.
SciDAVis currently uses the Qwt library for plotting which has two main drawbacks: It is geared toward displaying plot in widgets on screen while SciDAVis will focus on export quality. Secondly, it is backward compatible to Qt3 and shares it's limitations. Qt4's QGraphicsView is much more powerful than anything Qt3 offered and Qwt does not make use of that. LithoGraph is intended to replace Qwt completely. The goals are to use as many features from QGraphicsView as possible, support undo/redo, integrate with the aspect framework, flexible support of different coordinate systems (cartesian, polar, ternary, ...), separation into data and style (similar to CSS) with styles replacing the need for graph templates. LithoGraph still needs a lot of planning and probably should not be started before the aspect framework is completely implemented and ApplicationWindow is fully replaced. Once LithoGraph is in an advanced stage, new plot types including waterfall plots, polar charts, and ternary plots as well as axes breaks are planned.
Status: The requirements are known, the design is still open. No code written yet.