kexi project
Rapid Database Application Development
Development
"Microsoft Access for Linux"

Home Download FAQ Support Features Handbook Screenshots Screencasts Compile Kexi Development Authors Contact License Sponsorship Translate This Site

wiki navigation:

Front Page
[info] [diff] [login]
[recent changes]
[most popular]
You can donate
to Kexi Project:
Via PayPal

Spread the word about Kexi!
Get Kexi Now!

Built on the KDE technology
KDE

Member of the Calligra Suite

No Software Patents!

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
^ toc

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

^ toc

2. Reusing Form Designer

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

^ toc

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
^ toc

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.
^ toc

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]
^ toc

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.
^ toc

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
^ toc

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



Kexi - "MS Access for Linux" ... and Windows
© 2002-2007 Kexi Team
This content is available under GFDL
Last edited: September 8, 2005 by mart, visited 0 times.