|This is a design document|
The goal: Make it possible to create, modify, open and save KReport designs without touching the Designer's and Previewer's API and dependencies (QWidget, QGraphicsView).
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
[ KReportData ]
Usage in unit tests: KReportDesign, KReportDocument, KReportWriter (impl.) are first classes for autotesting. See Autotests for scenarios.
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
Qt Quick mode
Like for the headless mode, lack of QWidget/QGraphicsView dependencies is good for Qt Quick bindings and suitable APIs. This opens opportunity of supporting touch applications.
- Rename KoReportReportData, it's not about data
- During the API changes we have opportunity to rename Ko* prefixes to KReport too
This page was last modified on 1 August 2015, at 00:25. Content is available under Creative Commons License SA 4.0
unless otherwise noted.