KReport/API Changes: Difference between revisions

From KDE Community Wiki
Line 14: Line 14:
**Inherit KReportWriter to implement what we so far call 'renderers'
**Inherit KReportWriter to implement what we so far call 'renderers'
**KReportDocument+KReportWriter is like QPainter+QPaintDevice
**KReportDocument+KReportWriter is like QPainter+QPaintDevice
**Current API solutions are not the best, e.g. see KoReportRendererContext


<pre>
<pre>

Revision as of 09:28, 29 July 2015

Note

This is a design document


Design creation

Started: Jstaniek (talk) 08:59, 29 July 2015 (UTC)

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
  • 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.

Notes

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