![]() Qtopia Home - Classes - Hierachy - Annotated - Functions - Qt Embedded |
![]() |
There are two basic styles of application:
The main window of a document based application will present a list of items, or in some cases a list of sub-lists.
Note: The documents are not necessarily individual files. The entries in an address book for instance may be considered documents.
Document based applications should follow a standard navigational flow:
This is rarely needed. It is used when there are a number of lists that behave differently or have some incompatible properties. An example application is the Qtopia Messaging application. This application shows folders that have specific functions. The Outbox, Trash, Inbox, etc. all have particular properties that preclude grouping their items into one list.
The context menu must contain entries that act on all of the lists, and optionally a New entry.
Highlighting a list and pressing Select displays the List of Items. Pressing Back or Done must close the application.
This is the screen most applications will display when started via the launcher. It lists the documents that the application may view and/or edit. It is recommended that the menu contains a View Category... option to display only the items in the selected category.
The context menu should contain entries that act on all of the items, and optionally a New entry.
Highlighting an item and pressing Select should display a more detailed view of the highlighted item. Pressing Back or Done must return to the previous list of items or lists (if present), otherwise close the application.
When an item in the list is used to group or store information; selecting that list item should present the information about that item.
This screen displays a single item, and may allow navigation and activation of data within the view.
The context menu must contain entries that act only on the viewed item. If the application can edit the document, it should contain an Edit menu entry.
If the view contains elements that can be activated, then the Select key must activate the highlighted element. Pressing Back or Done must return to the list of items.
This screen allows a single item to be modified. Edit screens must be able to be canceled via the Cancel option found in the context menu.
Note: When a user selects the Done or Back option and nothing has been altered the button acts as the Cancel option otherwise the item will be stored. More information on this can be found in the ... section.
When creating or editing an item, the first tab must be displayed with the first input widget focused.
The context menu must be limited to those entries that act on the item being edited. Phones that do not offer a No button may automatically have a Cancel entry added to the end of the menu.
Pressing Back or Done must accept the changes and return to the view. Pressing Cancel must discard the changes and return to the view.
An application that can create or edit an item should provide the ability to remove an item of the same type.
Items are only able to be deleted when viewing there details hence only one at a time.
In order to maintain a consistent navigational flow, the following rules must be adhered to:
Note: In case there is no tabbed dialog it is very tempting to give the left and right buttons the same functionality as up and down. We have explicitly chosen NOT to do so in order to keep the user interface as consistent as possible, i.e. maintaining one way of doing things.
An input form should provide a simple and familiar way for the user to input data. The basic layout of an input form is a 2 columned table: the first column provides a label for the field found in the same row; the second is the input field.
The basic layout of an input form should remain consistent between all applications. It is also recommended that the same input form is used when creating and editing an item.
These applications allow a specific task to be performed. They do not operate on documents, though they may generate documents. Examples of task based applications are Clock and Calculator.
Always give an exported Class a d-pointer. For example:
--- exampleclass.h --- #ifndef EXAMPLE_CLASS_H #define EXAMPLE_CLASS_H class ExampleClassPrivate; class ExampleClass { public: // Some member functions private: ExampleClassPrivate *d; // The d-pointer. }; #endif ------------------------ --- exampleclass.cpp --- class ExampleClassPrivate { public: int variable; int anotherVariable; }; ExampleClass::ExampleClass() { d = new ExampleClassPrivate; } ExampleClass::~ExampleClass() { delete d; } ------------------------
Indenting: is always 4 characters with tab spaces set to 8 characters.
Other prefered code formatting is as follows:
class MyExampleClass { }; void MyExampleFunction() { int someVariable; if (TRUE) { // Something } else { // Something else } }
Copyright © 2001-2005 Trolltech | Trademarks | Qtopia version 2.1.1
|