KReport/API Changes

Note

This is a design document

Design creation

• Started: Jstaniek (talk) 08:59, 29 July 2015 (UTC)
• Task: https://phabricator.kde.org/T517
• Code: ssh://[email protected]/clones/kreport/staniek/work branch nonvisual-T517-staniek

The goal: Make it possible to create, modify, open and save KReport designs without touching the designer API.

New classes and relations between them proposed:

• KReportDesign: setContent(xml) loads, toString() saves, modelled after
  • We don't use KReportDocument name for this because actual document is: design+data
  • Addressed issue: .kreport format loading happened in KoReportDesigner's ctor without proper error reporting
• KReportDocument: design+data so it's more or less takes KReportDesign and KReportData args.
  • KReportDocument can be rendered on a KReportWriter
• KReportWriter is equivalent of QImageWriter, can use files or QIODevices
  • Inherit KReportWriter to implement what we so far call 'renderers'
  • KReportDocument+KReportWriter is like QPainter+QPaintDevice
  • Current API solutions are not the best, e.g. see KoReportRendererContext

[KReportDesign]
              >--builds-[KReportDocument]-->-is-used-in-[KReportWriter]--writes-to--[File/Screen/Printer]
[ KReportData ]

Usage in unit tests: KReportDesign, KReportDocument, KReportWriter (impl.) are first classes for autotesting. See Autotests for scenarios.

Headeless mode

The designer-independent APIs can lead us to a headless mode for report generation. Example command line for a kreport tool takes report design from file design.kreport employs the PDF renderer, receives data from data.csv, and outputs the PDF to file report.pdf:

% kreport --format PDF design.kreport --out report.pdf < data.csv

TODO

• Rename KoReportReportData, it's not about data

Notes

• During the API changes we have opportunity to rename Ko* prefixes to KReport too