Interface for import operations. More...

#include <AbstractImportFilter.h>

Inheritance diagram for AbstractImportFilter:

Public Member Functions
virtual QStringList	fileExtensions () const =0
	The file extension(s) typically associated with the handled format.
virtual AbstractAspect *	importAspect (QIODevice *input)=0
	Import an object from the specified device and convert it to an Aspect.
virtual QString	name () const =0
	A (localized) name for the filter.
QString	nameAndPatterns () const
	Uses name() and fileExtensions() to produce a filter specification as used by QFileDialog.
virtual	~AbstractImportFilter ()

Detailed Description

Interface for import operations.

The least common denominator of all import operations is that they read data from a device (typically, but not necessarily, a file), interpret it in a filter-specific way (as project files in SciDAVis/QtiPlot legacy format, Origin project, CSV table, image, ...) and convert it to the corresponding internal representation (Project, Table, Graph, ...). The application kernel takes care of all the pesky details, such as letting the user choose one or more files to import or adding the resulting Aspect either to the current project or a newly created one.

The main design goal was to make implementing import filters as easy as possible. Therefore, filter options are simply declared as Qt properties; the implementation does not have to bother with providing a GUI for its options (this task is taken over by ImportDialog). This approach allows fast prototyping of import filters, but leaves some things to be desired usability-wise (localized option labels, tool tips, intelligent layout, etc.). Some of these deficiencies could be overcome by adding extra methods to filters (e.g. Qstring labelText(const char * property_name)), but presumably one will want to replace the auto-generated GUI with a custom one once the filter is completely implemented and tested. This is done by providing a method "QWidget * makeOptionsGui();". The result of calling this method is then used by ImportDialog instead of the auto-generated GUI. The filter still has to inherit from QObject and use the Q_OBJECT macro, since otherwise there's no way of testing for the presence of this method.