Kexi Reporting

Table of Contents    Terms    1. Proposal: Reusing KWord (kotext) as Kexi reporting layer    2. Reusing Form Designer      KFD's elements to be reused      Differences between RD and FD:    5. Design Proposal      5.1. Reporting layers      5.1.1. More description      5.1.2. Questions      5.2. Report types    4. What about Kugar?      4.1. Problems

Terms

• RD - Report Designer
• FD - Form Designer

1. Proposal: Reusing KWord (kotext) as Kexi reporting layer

2. Reusing Form Designer

Report Designer's GUI is highly similar to Form Designer's one.

KFD's elements to be reused

• Text labels. Support for text labels means either labels with fixed content and variable content:

 Name:           [John Smith]
 fixed content variable content

Differences between RD and FD:

• RD needs support for printing units as points, inches, cm (whatever configured, it's already offered by kofficecore lib). Form Designer's unit is simply pixels.
• Although FD has (planned) feature of scaling (just in design mode to improve convenience), after switching to data mode, there's one defined "100%" scale. RD has no fixed scale, on printing, everything is scaled regarding to page settings, etc.

5. Design Proposal ^ toc

5.1. Reporting layers

 Legend for grammar-like description:
  {0,1} - 0 or 1
  * - 0 or more
  | - or
  details[n] - n-th level of details

 report -> report_header{0,1}, page*, report_footer{0,1}
 page -> page_header{0,1}, details[1]*, page_footer{0,1}
 details[n] -> details_header[n]{0,1}, details_contents[n]{0,1}, details_footer[n]{0,1}
 details_contents[n] -> contents_frame | details[n+1]

5.1.1. More description

• details_contents
  • fullPage attribute (bool) - true means the contents should take entire page's area
  • size attribute (QSize) - used when fullPage is false, ^ toc

5.1.2. Questions

• data fields can expandable to if their data is too large for original size... but this requires a bit difficult algorithm because other fields need to be moved down/left after such resize. LOW PRIORITY TODO.

5.2. Report types

• Graphical report, with layout designed in point metrics
• PLANNED FOR LATER: Text only report, generated with fixed fonts of a given size

4. What about Kugar? ^ toc

4.1. Problems

• Could Kugar painting be reused?
  • Kugar's painting routine is based on iterating over DOM nodes, while we would like to iterate over QWidget tree as in forms.
  • We want to use our factories to allow tweaking a way how a given field type is painted. Kugar has only a fixed, hardcoded set of displayable objects provided like a label, data field
  • As Alexander Dymo pointed out, Kugar's engine is not flexible enough to e.g. print out many frames in row with automatical layout (see example below).

 +------+------+
 |frame1|frame2|
 |      |      |
 +------+------+
 |frame3|frame4|
 |      |      |
 +------+------+
 |frame5|frame6|
 |      |      |
 +------+------+

See also: Malaga_aKademy2005_Discussions