Viadeo Twitter Google Bookmarks ! Facebook Digg del.icio.us MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites 
Logo Documentation Qt ·  Page d'accueil  ·  Toutes les classes  ·  Toutes les fonctions  ·  Vues d'ensemble  · 

Qt Extended Style Guide: Widgets

Layout

For keypad-based devices, all widgets that can accept focus should be laid out vertically (i.e. they should never be placed next to each other). Keypad navigation relies on the Up and Down keys to move focus between widgets, and the Left and Right keys are reserved for switching between tabs. Because of this, having two widgets that accept focus positioned side by side causes unintuitive navigation.

Labels

  • Labels should not have ":" at the end.
  • All labels should conform to the Naming conventions .
  • Text labels should have consistent alignment. Consider using QFormLayout for this.

Buttons

  • Button labels should follow the labeling scheme described in the Labels section.
  • For some applications it is desirable to associate keypad keys to buttons displayed in the applications (as is done in the the Clock application for the stop watch). This is not recommended however if it is necessary the label should include the associated key's label.

Tabs

If the user presses the Left or Right key while in a tabbed window it should change the visible tab. To allow this, no widget may use the Left or Right keys when in navigation focus mode.

The number of tabs in a tab bar should be limited so that all of the tabs can fit horizontally with no scrolling.

Tabs are usually placed at the top of the screen. Other cases are supported, but not recommended (there are some drawbacks to using other configurations. For example, even if tabs are arranged vertically, left and right will still be used move between them).

A tab bar should only contain tabs of the same type (i.e. don't mix icon tabs with text tabs in the same tab bar). Recommended choices are:

  • Text-only tabs
  • Icon+text tabs

Lists

For keypad-based devices, the list highlight when opening a list should be the first item (or the previously selected item when returning to a list). For touchscreen devices, the list highlight should be transient: it should appear when an item is pressed, and disappear once released.

Menus

  • Menu options should be hidden when unavailable
  • A menu should have the top-most item selected by default (for keypad-based devices)
  • A menu separator should be used to group options that perform associated functionality such as New, Edit and Delete.
  • Menu options with predefined names such as Cancel should use the appropriate icon.

The ordering of items in a menu should be based on the following ordering:

  • New
  • Edit
  • Modify commands, e.g. Crop
  • Delete
  • Action commands, e.g. Beam, Duplicate, Copy, Paste
  • View commands, e.g. Today, View Category...
  • Options commands, e.g. Settings
  • (separator) (added by system)
  • Help (added by system)
  • Cancel (added by system)

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. That is, the "..." extension 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 Using the "..." label label for a full explanation.

Where an application is structured as a list of items and selecting an item shows its details, the menu for the list should not include any actions that are directly related to a single item. Actions that are applied to an individual item (and never to a list) should be placed in the menu that becomes available when the details of an item are shown. (Menu, Down-past-New, Select-Edit is just as many steps as Select-Item, Menu, Select-Edit).

When particular widgets are selected the softkey menu may change its option list. However, promoting this functionality is not recommended.

Menu Names

Menu options should follow all conventions found in the Naming conventions . An acronym or abbreviation for a menu item should only be used if the label doesn't fit on the screen OR if an acronym or abbreviation already exists for the current label (as this promotes consistency in the use of text labels).

Menu-like Dialogs

Some dialogs consist of a list of items, only one of which the user needs to select in order to complete an operation. In a small number of cases the user may wish to do more with the item, such as edit it via the menu.

Such list dialogs are Menu-like Dialogs, and should behave like menus:

  • Highlighting an item should have no long-term effect.
  • Selecting an item should close the window and return to the previous view (even if that means closing the application).
  • The soft key icon for Key_Back should be Cancel, not the usual Back.

To assist in creating Menu-like dialogs use the function

    QtopiaApplication::setMenuLike();

which maps the soft keys and menu correctly for the dialog.

If the dialog has a menu, consider having Activate, or Select in the menu, but ensure this command does not close the dialog.

Examples include: Profile selection, Speed dial action selection.

Dialogs

A dialog's title should describe the process that is currently taking place in the dialog. For example, Editing Event, Creating Event. A dialog title should not have its text appended with "...".

Dialogs are either shown full screen or at the bottom of the screen, depending upon the height of the dialog's sizeHint(). A dialog with a size hint greater than three fifths of the screen height will be shown fullscreen, otherwise it will be positioned at the bottom of the screen at its preferred height. Dialogs always use the full width of the screen.

Message dialogs that allow a positive or negative response should be phrased such that the user can answer Yes or No, rather than OK or Cancel.

Informative Message dialogs should only allow the Back softkey menu bar option.

Message boxes should allow no more than two options. Three or more options are difficult for the user to process. If it is absolutely necessary to provide three or more options a list of options should be provided via a Menu-like Dialog.

Custom Widgets

Existing Qt widgets should always be used where possible. If a custom widget must be used, make sure that such a widget does not already exist.
Publicité

Best Of

Actualités les plus lues

Semaine
Mois
Année
  1. « Quelque chose ne va vraiment pas avec les développeurs "modernes" », un développeur à "l'ancienne" critique la multiplication des bibliothèques 94
  2. Apercevoir la troisième dimension ou l'utilisation multithreadée d'OpenGL dans Qt, un article des Qt Quarterly traduit par Guillaume Belz 0
  3. Les développeurs ignorent-ils trop les failles découvertes dans leur code ? Prenez-vous en compte les remarques des autres ? 17
  4. Pourquoi les programmeurs sont-ils moins payés que les gestionnaires de programmes ? Manquent-ils de pouvoir de négociation ? 42
  5. Quelles nouveautés de C++11 Visual C++ doit-il rapidement intégrer ? Donnez-nous votre avis 10
  6. Adieu qmake, bienvenue qbs : Qt Building Suite, un outil déclaratif et extensible pour la compilation de projets Qt 17
  7. 2017 : un quinquennat pour une nouvelle version du C++ ? Possible, selon Herb Sutter 9
Page suivante

Le blog Digia au hasard

Logo

Créer des applications avec un style Metro avec Qt, exemples en QML et C++, un article de Digia Qt traduit par Thibaut Cuvelier

Le blog Digia est l'endroit privilégié pour la communication sur l'édition commerciale de Qt, où des réponses publiques sont apportées aux questions les plus posées au support. Lire l'article.

Communauté

Ressources

Liens utiles

Contact

  • Vous souhaitez rejoindre la rédaction ou proposer un tutoriel, une traduction, une question... ? Postez dans le forum Contribuez ou contactez-nous par MP ou par email (voir en bas de page).

Qt dans le magazine
Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. Qt qtextended4.4
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP !
 
 
Developpez.com

Nous contacter

Participez

Informations légales

 
Services

Forum Qt

Blogs

Hébergement

 
Partenaires

Hébergement Web