📄 styleguide.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><!-- /home/edba/dist/qtopia/main-Sunday/qtopia/doc/styleguide.doc:1 --><html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Qtopia Style Guide</title><style type="text/css"><!--h3.fn,span.fn { margin-left: 1cm; text-indent: -1cm; }a:link { color: #004faf; text-decoration: none }a:visited { color: #672967; text-decoration: none }body { background: #ffffff; color: black; }--></style></head><body><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td width="200" align="left" valign="top"><a href="index.html"><img height="27" width="472" src="dochead.png" border="0"></a><br><font face="Arial,Helvetica,Geneva,Swiss,SunSans-Regular" align="center" size=32>Qtopia</font> <a href="index.html">Home</a> - <a href="qtopiaclasses.html">Classes</a> - <a href="qtopiaannotated.html">Annotated</a> - <a href="qtopiafunctions.html">Functions</a> - <a href="qtindex.html">Qt Embedded</a></td><td align="right" valign="top"> <table border="0" cellpadding="0" cellspacing="0" width="137"> <tr> <td><a href="http://www.trolltech.com/company/about/trolls.html"><img height="100" width="100" src="face.png" border="0"></a></td> <td><img height="100" width="100" src="qtlogo.png" align="top" border="0"></td> </tr> </table></td></tr></table><h1 align=center>Qtopia Style Guide</h1><p> Contents<!-- toc --><ul><li><a href="#1"> Introduction</a><li><a href="#2"> Main Window</a><ul><li><a href="#2-1"> Document Based Applications</a><ul><li><a href="#2-1-1"> List of Lists</a><li><a href="#2-1-2"> List of items</a><li><a href="#2-1-3"> View of a Single Item</a><li><a href="#2-1-4"> Edit Single Item</a><li><a href="#2-1-5"> Deleting a single item</a></ul><li><a href="#2-2"> Task Based Applications</a></ul><li><a href="#3"> Navigational Flow</a><li><a href="#4"> Input Form Layout</a><li><a href="#5"> Labels</a><li><a href="#6"> Buttons</a><li><a href="#7"> Input fields</a><ul><li><a href="#7-1"> Text fields</a><li><a href="#7-2"> Number fields</a></ul><li><a href="#8"> Tabs</a><li><a href="#9"> Menus</a><ul><li><a href="#9-1"> Menu Names</a><li><a href="#9-2"> Menu-like Dialogs</a></ul><li><a href="#10"> Lists</a><li><a href="#11"> Dialogs</a><li><a href="#12"> Interprocess Actions</a><li><a href="#13"> Application Naming</a><li><a href="#14"> Naming Conventions <!-- index naming conventions --><a name="naming-conventions"></a></a><ul><li><a href="#14-1"> Abbreviations</a><li><a href="#14-2"> Acronyms</a><li><a href="#14-3"> Using the "..." label</a><ul><li><a href="#14-3-1"> Examples of when to use "..."</a><li><a href="#14-3-2"> Examples of when not to use "..."</a></ul><li><a href="#14-4"> Currently used label names <!-- index used-label-names --><a name="used-label-names"></a></a></ul><li><a href="#15"> Qtopia Phone Keys</a><li><a href="#16"> Standard Icons and Usage</a></ul><!-- endtoc --><p> <h2> Introduction</h2><a name="1"></a><p> This document describes the rules to be followed when designing an application for the Qtopia Phone Edition. The focus is on consistency. Think very carefully before departing from the preferred style.<p> <h2> Main Window</h2><a name="2"></a><p> The main window is the screen that the user will see upon entering the application via the launcher. Qtopia Phone applications do not have a menu bar, tool bar, or task bar. Each screen may have a <em>Context Menu</em> which provides options appropriate for the current screen.<p> There are two basic styles of application:<ul><li> Document Based - views and possibly edits documents.<li> Task based - allows a specific task to be performed, e.g. view the time.</ul><p> All applications should store their exited state and resume such a state when the application is invoked again.<p> <h3> Document Based Applications</h3><a name="2-1"></a><p> The main window of a document based application will present a list of items, or in some cases a list of sub-lists. Note that the <em>documents</em> are not necessarily individual files. The entries in an address book may be considered documents.<p> Document based applications must all follow the same navigational flow:<ul><li> List of Lists (if necessary).<li> List of Items.<li> View of a Single Item.<li> Edit Single Item.<li> Deleting a Single Item.</ul><p> <h4> List of Lists</h4><a name="2-1-1"></a><p> 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.<p> The context menu must contain entries that act on all of the lists, and optionally a <em>New</em> entry.<p> Highlighting a list and pressing <em>Select</em> displays the List of Items. Pressing <em>Back</em> or <em>Done</em> must close the application.<p> <h4> List of items</h4><a name="2-1-2"></a><p> 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 contain a <em>View Category...</em> option to display only the items in the selected category.<p> The context menu must contain entries that act on all of the items, and optionally a <em>New</em> entry.<p> Highlighting a document and pressing <em>Select</em> displays the view of the highlighted item. Pressing <em>Back</em> or <em>Done</em> must return to the previous list of items or lists (if present), otherwise close the application.<p> When an item in the list is used to group or store information; selecting that list item should present the information about that item.<p> <h4> View of a Single Item</h4><a name="2-1-3"></a><p> This screen displays a single item, and may allow navigation and activation of data within the view.<p> The context menu must contain entries that act only on the viewed item. If the application can edit the document, it should contain an <em>Edit</em> menu entry.<p> If the view contains elements that can be activated, then the <em>Select</em> key must activate the highlighted element. Pressing <em>Back</em> or <em>Done</em> must return to the list of items.<p> <h4> Edit Single Item</h4><a name="2-1-4"></a><p> This screen allows a single item to be modified. Edit screens must be able to be cancelled via the <em>Cancel</em> option found in the context menu.<p> <em>NOTE</em>: When a user selects the <em>Done</em> or <em>Back</em> option and nothing has been altered the button acts as a <em>Cancel</em> option otherwise the item will be stored.<p> When viewing an item, the first tab must be displayed with the first widget in the tab having the default focus.<p> The context menu must be limited to those entries that act on the item being edited. Phones that do not offer a <em>No</em> button may automatically have a <em>Cancel</em> entry added to the end of the menu.<p> Pressing <em>Back</em> or <em>Done</em> must accept the changes and return to the view. Pressing <em>Cancel</em> must discard the changes and return to the view.<p> <em>NOTE</em>: Applications that provide beaming capabilities should only allow single items to be beamed. This means:<ul><li> In a list of items the selected or focused item should be beamed.<li> When an item is viewed it should be beamed.</ul>This means that applications should not provide "Beam all" functionality.<p> <h4> Deleting a single item</h4><a name="2-1-5"></a><p> A confirmation dialog should always be presented when deleting a single item.<p> An application that can create or edit an item should provide the ability to remove that same item.<p> It should be possible to remove an item when viewing it or when it has been highlighted in a list of items.<p> <h3> Task Based Applications</h3><a name="2-2"></a><p> 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 <em>Clock</em> and <em>Calculator</em>.<p> <h2> Navigational Flow</h2><a name="3"></a><p> In order to maintain a consistent navigational flow, the following rules must be adhered to:<ul><li> When moving <em>forward</em> (e.g. by pressing <em>Select</em> or selecting <em>Edit</em> from the menu), the displayed screen must be in its <em>initial state</em>. For example, in a list of items the top-most item must be highlighted.<li> When moving <em>back</em> (e.g. by pressing <em>Back</em> or <em>No</em>), the previously viewed screen must be displayed in the same state that it was in when left. For example, if item <em>D</em> was highlighted then viewed, pressing <em>Back</em> in the view must return to the list with item <em>D</em> still highlighted.<li> The <em>left</em> and <em>right</em> buttons are used for moving between tabs in a tabbed dialog.<li> The <em>up</em> and <em>down</em> buttons are used for moving between fields in a dialog.<li> To edit a field you have to focus it first using up/down and then press <em>select</em>.<li> The <em>select</em> button is also used to move through tabs (basically the same as pressing <em>right</em>).</ul><p> <em>NOTE</em>: In case there is no tabbed dialog it is very tempting to give the <em>left</em> and <em>right</em> buttons the same functionality as <em>up</em> and <em>down</em>. We have explicitely chosen NOT to do so in order to keep the user interface as consistent as possible, i.e. maintaining one way of doing things.<p> <h2> Input Form Layout</h2><a name="4"></a><p> Input forms provide a simple and familar way in which 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.<p> The label and input field should be left aligned in their appropriate columns.<p> The default padding values are provided in the image found below.<center><img src="layout.png"></center> <p> <h2> Labels</h2><a name="5"></a><p> The rules listed below should be followed when creating a label:<p> <ul><li> Not all labels should have be appended with ":" prior to the input field.<li> There should never be a blank label listed in or for any widget.<li> All labels should conform to the Naming Conventions.<li> Text labels should be left aligned.</ul><p> Please utilize the used label names table for consistent label names across applications.<p> <h2> Buttons</h2><a name="6"></a><p> What buttons should do. Using soft keys.<p> <h2> Input fields</h2><a name="7"></a><p> By default "T9" support should not be enabled in any text input field unless previously changed.<p> The pen icon should only be used when "Cut", "Copy" and "Paste" options or a subset are available.<p> <h3> Text fields</h3><a name="7-1"></a><p> Input fields should only remember the input type for that specific field (not all widgets of that type).<p> <h3> Number fields</h3><a name="7-2"></a><p> No characters other than numbers should be allowed in this field. Letters should be appended as labels or combo-boxes where appropriate. For example, "10 mins" should only display "10" and have mins appended as a label.<p> <h2> Tabs</h2><a name="8"></a><p> Tab widgets should be able to gain focus from the user pressing either of the <em>up</em> or <em>down</em> directional pad buttons. When a user has the tab selected pressing the <em>select</em> button should allow the them to proceed to the next available tab.Pressing the <em>up</em> or <em>down</em> directional pad buttons again will return the focus to the dialog, selecting the first or last element in the dialog.<p> If the user presses either of the <em>left</em> or <em>right</em> directional pad buttons while in a tabbed dialog, the user should be able to change the tab with the focus shifting to the tab's label or icon.<p> <h2> Menus</h2><a name="9"></a><p> The ordering of items in a menu must be:<p> <ul><li> New<li> Edit<li> Modify commands, e.g. <em>Crop</em><li> Delete<li> <a href="action.html">Action</a> commands, e.g. <em>Beam</em>, <em>Duplicate</em><li> View commands, e.g. <em>Today</em>, <em>View</em> Category...<li> Options commands, e.g. <em>Settings</em><li> Help (added by system)</ul><p> When the selection of a menu item leads to a new dialog, the menu item label should only be suffixed with "..." if the command is being further refined. In other words, the "..." extention should only be placed on the end of menu names when a selection of items is going to be offered or additional commands have to be specified. No space should be left between the first '.' and the last character of the menu name. Please refer to Special Naming Cases: Using the "..." label for a full explanation.<p> <em>NOTE</em>: Application menu labels do not have to be appended with the type of item on which they are performing the action. For example, only "Edit" is required on the menu label, not "Edit Event".<p> <ul>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -