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

= AutoForm

See AutoForms.

Datasheet view

Datasheet view of a form is in practice the same view as a data sheet view of a table or query data. Users can see a table filled with records of data. KexiDataTableView class can be reused for that.

The 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 - just by a toolbar button or so.

Status: TODO

Subform Widget

A subform is not a special type of a form but a container widget provided to define area within a parent form, to display a child form. This way, nesting a form within another form is possible. Also, a deeper level of nesting would be possible, assuming it makes sense and is usable to the user.

Status: MOSTLY IMPLEMENTED since KEXI 0.8; HIDDEN for now; refresh is needed

Special features

(not implemented)

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

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, using a form presenting the currently highlighted data row (record) in the same time parallel. To implement this, a combination of a TableView and a regular form view is needed. For example, one above another.

+--------------------------------------+
|   Table View with multiple records   |
+--------------------------------------+
| Form View presenting a single record |
+--------------------------------------+

This additional form section would most probably be an autoform, so user would not bother about designing it.

Notes:

• A KDE's DataKiosk application already has a Data Table with Form View functionality, separated using tabs.[1]
• MSA 2007 adopted the idea and named it as split forms.

See:

• SPLIT FORMS: BEST OF BOTH WORLDS FOR EDITING AND VIEWING DATA
• Split Forms: Rich Datasheets

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