Kexi/Plugins/Reports/Object tree: Difference between revisions

Revision as of 22:49, 25 September 2014

Design page for task: "Add object tree for the Report Designer".

Kexi Form Designer has its object tree. The same feature for reports is needed.

Picture1: In many aspects the report's tree is similar to form's tree, so should be designed with code sharing and similarities in mind:

R1. Use the tab as in the form's tree, see the Picture1. The only difference that the tab's tooltip should say "Elements", not "Widgets". This difference should be used where applicable in other places.
R2. The tree must present hierarchy of all sections, then elements in each section. Example, for this report:

the tree should have the following items:

R3. Even invisible sections shall be displayed in the tree as items. Display them using semitransparent text color to indicate their invisible property.
R4. The tree should have two columns: Element name, Type
R5. Report itself is an (selectable) object and has properties, so it shall be a root of the tree.
R6. Each item in the tree should have a small icon, like the form's tree has. Icons are provided by the plugin(s) that provide the report elements creation (the Report Design toolbar uses them too).
R6.1. For the "report" tree item use the "report" icon.
R6.1. For sections use the "report" icon temporarily. When section icons are created, they will be used.
R7. Clicking on any tree item should change current selection in the report design.
R8. Similarly, clicking on any real report element (or multiple elements), including section or the report itself, should update current selection in the tree.
R9. Like in the form's tree, report's tree should allow multiple item selection using Ctrl+LMB. Selection of report elements should then be updated accordingly.
R10. Like in the form's tree, clicking with RMB on any report tree item should display the same cotext menu that is displayed when the item itself is clicked.
R11. The objects tree tab should be present in Design view only. This can be easily assured when the same API for tabs is used as in the case of form's tree.

TODO: Plan code sharing, refactoring here...

R3.1. Show/hide action for such tree items should be available for quick access. TODO: explain this.

@@ Line 19: / Line 19: @@
 *R4. The tree should have two columns: Element name, Type
 *R5. Report itself is an (selectable) object and has properties, so it shall be a root of the tree.
-*R4. Each item in the tree should have a small icon, like the form's tree has. Icons are provided by the plugin(s) that provide the report elements creation (the Report Design toolbar uses them too).
+*R6. Each item in the tree should have a small icon, like the form's tree has. Icons are provided by the plugin(s) that provide the report elements creation (the Report Design toolbar uses them too).
+*R6.1. For the "report" tree item use the "report" icon.
+*R6.1. For sections use the "report" icon temporarily. When section icons are created, they will be used.
+*R7. Clicking on any tree item should change current selection in the report design.
+*R8. Similarly, clicking on any real report element (or multiple elements), including section or the report itself, should update current selection in the tree.
+*R9. Like in the form's tree, report's tree should allow multiple item selection using Ctrl+LMB. Selection of report elements should then be updated accordingly.
+*R10. Like in the form's tree, clicking with RMB on any report tree item should display the same cotext menu that is displayed when the item itself is clicked.
+*R11. The objects tree tab should be present in Design view only. This can be easily assured when the same API for tabs is used as in the case of form's tree.
 *TODO...