Kexi/Plugins/Forms/Analysis

Introduction

KEXI uses libraries simplified and forked from KFormDesigner (KFD) to implement form design and presentation features. In particular advanced widgets and advanced properties have been hidden from the user's eyes. KEXI also adds more intuitive options not found in Qt Designer or KFD, such as a separate widget for pictures and another for text label.

Anatomy of a form window

 2005-02-23, jstaniek

Inheritance diagrams

 KexiFormScrollView -> [ KexiScrollView,
                          KexiRecordNavigatorHandler,
                          KexiSharedActionClient,
                          KexiDataAwareObjectInterface,
                          KexiFormDataProvider ]

 KexiFormDataProvider -> KexiDataProvider

 KexiFormView -> KexiDataAwareView -> KexiViewBase

 KexiDBForm -> [ QWidget,
                  KFormDesigner::FormWidget,
                  KexiDataItemInterface ]

 KexiDBLineEdit -> [ KLineEdit,
                     KexiDataItemInterface ]

 KexiSubForm -> [ QScrollView ]

KEXI form types

 jstaniek, mar 2005

Standard form

A form which is designable using the KFD component. Its content consumes a full size of the window. Upon design, user can easy resize contents thanks to the existence of the special outer area.

When the form is previewed (Data Mode), outer area disappears, and additional space becomes empty.

Data-aware, a single forms usually displays a single data record, a row. In more complex case a form can be not data-aware but instead can just act as a container for a number of user-visible texts and buttons, and one or more data-aware subforms, see below.

[TODO: a screen shot with annotation]

Status: IMPLEMENTED in KEXI 0.8

Continuous form

A continuous form consists of a number of horizontal, full-width areas. Each area is in fact a separate form canvas displaying a single database record. Having a continuous form without binding it to a data source is not a proper use case.

Upon design time of a continuous form, user edits contents of a single form area, what is largery similar activity to editing a standard single form. After switching to Data Mode, the designed form will be multiplied many times to fill entire container's area, and to display all data records.

Continuous forms can be used as top-level forms or can be nested inside a standard form as a subform.

Status: TODO

2.4. Datasheet view

This is the same solution as data view for tables or queries: user can see a table filled with records of data. KexiDataTableView class is reused for that.

Datasheet view is just other method of displaying a form's data - the data source definition (a query) is the same as form's data. This view should be accessible without additional design efforts at user's side - just by a toolbar button or so.

Status: TODO

2.5. Subform Widget

In fact, subform is not a special type of a form, it's a container widget able to display another form within it's parent form and thus it's able to nest a form within another form. It's possible to do a dipper level of nesting, even while usability of such a thing is not necessary clear.

Status: MOSTLY IMPLEMENTED since KEXI 0.8; HIDDEN for now

2.5.1. Special features

(not implemented)

"hideIfEmpty" property hides a subform if it doesn't contain any records. After hidding, the form should take the same amount of space.

2.6. Form helper within Table View

Sometimes, a user may find it more convenient to navigate through data rows using TableView and at the same time, having a form for current row's data (record) visible in parallel. The solution requires just to insert a "form section" below the tabular view.

(the screenshot is taken from OO.org base 2.0 Beta)

This additional form section will be most probably an autoform, so user won't care about defining it.

Note1: DataKiosk application already has Data Table/Editor Form functionality, separated using tabs.

Note2: MSA 2007 adopted the idea and named it as split forms. See here, here and here.

Status: TODO

2.7. Quick Forms

The proposal is that original MSA's 'autoform' entity (i.e. a form which is created by single button click, after just picking a data source) could be named somewhat like 'Quick Forms'. Most probably, AutoForms can be used for generating a form quickly.

3. Problems

3.1. Issues with IDEAl and Tabbed-Pages modes

In IDEAl and tabbed pages mode, all forms are maximized, there is no "restore" mode. However, this mode would be more appropriate, in particular when previewing. A possible solution would be to create first a workspace (or someting similar) and then to create forms in "restore" mode.

3.2. Form Resize Modes for form windows inside KEXI

 2004-12-14, jstaniek

A form is built in three layers: KexiDBForm widget is an only child of KexiFormScrollView (QScrollView) which is a main widget inserted into KexiFormView (KexiViewBase subclass). Thanks to reimplementing QScrollView, we've got ability of displaying scroll bars on demand.

Following resize modes are implemented for data view mode:

Auto (the default). Resize policy of KexiFormScrollView is set to AutoOneFit (see QScrollView::setResizePolicy()). This means that:
- if a form window is smaller than form's size predefined on design time (by dragging its boundaries), scrollbars are presented (or one of them)
- else: scrollbars are hidden and form's surface is resized, so no gray scrollview's surface is visible at all.
- When maximized, form's window resizes it's contents.
- On opening, if it's in restored mode (unmaximized), (it's possible for childframe or toplevel mode) form's window size hint equals to default form's size predefined on design time, as described above.
- Form's boundaries (left and bottom) are invisible, since form's surface takes entire window's contents.
- Note Auto doesn't mean that form's widget are layed out. They can be layed out to better fit contents only if user defined form's layout.

Fixed. Resize policy of KexiFormScrollView is set to Manual. Form's contents are not resized upon form window resize/maximizing/restoring.
- Form's (left and bottom) boundaries are visible, the form's surface is top-left aligned. This is regardless of form's layout settings. Grayed surface is visible beyond boundaries.

3.3. Related form's properties

"Horizontal scrollbar" : "As needed"(def) | "Always" | "Never"
"Vertical scrollbar" : "As needed"(def) | "Always" | "Never"

3.4. Notes

These are KEXI-specific modes, available using property editor (not available from KFormDesigner). This can be changed in the future for user's convenience.
In Design view mode the QScrollView container has always Manual resize policy, what enables user to drag form's boundaries.

3.5. "Edit indicator" for standard forms

Standard form (not continuous) can usually take entire screen size. In MSA there's displayed a record indicator with an arrow pointing to the current record, see [1] on the picture.

Since it's good for continuous forms, it's a nonsense for standard forms since there's always displayed one record at the time.

The proposal is to move edit indicator down to the record navigator, on the left hand, see [2] on the picture. It's "pen" icon will be displayed only on edit time. Except edit time, there will be empty area displayed in this place.

Status: IMPLEMENTED in KEXI 0.8