Im not sure about the second one. KReportData is an interface that provides actual data ?

In T4492#75927, @piggz wrote:

Im not sure about the second one. KReportData is an interface that provides actual data ?

Well, since d4a0b95943 it's description is

@brief Abstraction of report data source

What's inside? Abstraction of:

• opening/closing
• cursor operations: bi-directional movement, value retrieval
• introspection providing name of the source, field names
• sort configuration
• a simple condition/filtering (TODO: addExpression() would be better addCondition()?)

...

It all looks like an interface to a data source. So KReportAbstractDataSource or KReportDataSource. I'd pick the latter.

TODO: what's dataSourceNames()?

Ok....

dataSourceNames is used in the chart plugin....i cant fully remember why, but it appears to be a human-readable name for the data source.

In T4492#75968, @piggz wrote:

Ok....

dataSourceNames is used in the chart plugin....i cant fully remember why, but it appears to be a human-readable name for the data source.

I see. So it's about the GUI :)

For that how about:

• dataSources() -> dataSourceNames() and make it abstract because the implementation is always needed anyway
• completely rework dataSourceNames() as below

Then we have:

//! Return a list of data source names available for this data source
//! Works after the source is opened
virtual QStringList dataSourceNames() const = 0;

//! Return data source caption for specified @a dataSourceName
//! It is possibly translated. As such it is suitable for use in GUIs.
//! Default implementation just returns @a dataSourceName.
virtual QString dataSourceCaption(const QString &dataSourceName) const;

It is handy to have dataSourceCaptions as a QStringList to be used as the value param in Kproperty ... do we leave this to the caller?

Yes, I'd say, let's have the API minimal, dataSourceCaption() makes it more like a model.