| 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|---|
| 2 | <!-- /home/espenr/tmp/qt-3.3.8-espenr-2499/qt-x11-free-3.3.8/doc/focus.doc:36 -->
|
|---|
| 3 | <html>
|
|---|
| 4 | <head>
|
|---|
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
|---|
| 6 | <title>Keyboard Focus Overview</title>
|
|---|
| 7 | <style type="text/css"><!--
|
|---|
| 8 | fn { margin-left: 1cm; text-indent: -1cm; }
|
|---|
| 9 | a:link { color: #004faf; text-decoration: none }
|
|---|
| 10 | a:visited { color: #672967; text-decoration: none }
|
|---|
| 11 | body { background: #ffffff; color: black; }
|
|---|
| 12 | --></style>
|
|---|
| 13 | </head>
|
|---|
| 14 | <body>
|
|---|
| 15 |
|
|---|
| 16 | <table border="0" cellpadding="0" cellspacing="0" width="100%">
|
|---|
| 17 | <tr bgcolor="#E5E5E5">
|
|---|
| 18 | <td valign=center>
|
|---|
| 19 | <a href="index.html">
|
|---|
| 20 | <font color="#004faf">Home</font></a>
|
|---|
| 21 | | <a href="classes.html">
|
|---|
| 22 | <font color="#004faf">All Classes</font></a>
|
|---|
| 23 | | <a href="mainclasses.html">
|
|---|
| 24 | <font color="#004faf">Main Classes</font></a>
|
|---|
| 25 | | <a href="annotated.html">
|
|---|
| 26 | <font color="#004faf">Annotated</font></a>
|
|---|
| 27 | | <a href="groups.html">
|
|---|
| 28 | <font color="#004faf">Grouped Classes</font></a>
|
|---|
| 29 | | <a href="functions.html">
|
|---|
| 30 | <font color="#004faf">Functions</font></a>
|
|---|
| 31 | </td>
|
|---|
| 32 | <td align="right" valign="center"><img src="logo32.png" align="right" width="64" height="32" border="0"></td></tr></table><h1 align=center>Keyboard Focus Overview</h1>
|
|---|
| 33 |
|
|---|
| 34 |
|
|---|
| 35 |
|
|---|
| 36 | <p> <!-- index keyboard focus --><a name="keyboard-focus"></a>
|
|---|
| 37 | <p> Qt's widgets handle keyboard focus in the ways that have become
|
|---|
| 38 | customary in GUIs.
|
|---|
| 39 | <p> The basic issue is that the user's keystrokes can be directed at any
|
|---|
| 40 | of several windows on the screen, and any of several widgets inside
|
|---|
| 41 | the intended window. When the user presses a key, they expect it to go
|
|---|
| 42 | to the right place, and the software must try to meet this
|
|---|
| 43 | expectation. The system must determine which application the keystroke
|
|---|
| 44 | is directed at, which window within that application, and which widget
|
|---|
| 45 | within that window.
|
|---|
| 46 | <p> <h2> Focus motion
|
|---|
| 47 | </h2>
|
|---|
| 48 | <a name="1"></a><p> The customs which have evolved for directing keyboard focus to a
|
|---|
| 49 | particular widget are these:
|
|---|
| 50 | <ol type=1>
|
|---|
| 51 | <p> <li> The user presses Tab (or Shift+Tab) (or sometimes Enter).
|
|---|
| 52 | <p> <li> The user clicks a widget.
|
|---|
| 53 | <p> <li> The user presses a keyboard shortcut.
|
|---|
| 54 | <p> <li> The user uses the mouse wheel.
|
|---|
| 55 | <p> <li> The user moves the focus to a window, and the application must
|
|---|
| 56 | determine which widget within the window should get the focus.
|
|---|
| 57 | <p> </ol>
|
|---|
| 58 | <p> Each of these motion mechanisms is different, and different types of
|
|---|
| 59 | widgets receive focus in only some of them. We'll cover each of them
|
|---|
| 60 | in turn.
|
|---|
| 61 | <p> <h3> Tab or Shift+Tab.
|
|---|
| 62 | </h3>
|
|---|
| 63 | <a name="1-1"></a><p> Pressing Tab is by far the most common way to move focus using the
|
|---|
| 64 | keyboard. Sometimes in data-entry applications Enter does the same as
|
|---|
| 65 | Tab. We will ignore that for the moment.
|
|---|
| 66 | <p> Pressing Tab, in all window systems in common use today, moves the
|
|---|
| 67 | keyboard focus to the next widget in a circular per-window list. Tab
|
|---|
| 68 | moves focus along the circular list in one direction, Shift+Tab in the
|
|---|
| 69 | other. The order in which Tab presses move from widget to widget is
|
|---|
| 70 | called the tab order.
|
|---|
| 71 | <p> In Qt, this list is kept in the <a href="qfocusdata.html">QFocusData</a> class. There is one
|
|---|
| 72 | <a href="qfocusdata.html">QFocusData</a> object per window, and widgets automatically append
|
|---|
| 73 | themselves to the end of it when <a href="qwidget.html#setFocusPolicy">QWidget::setFocusPolicy</a>() is
|
|---|
| 74 | called with an appropriate <a href="qwidget.html#FocusPolicy-enum">QWidget::FocusPolicy</a>. You can customize
|
|---|
| 75 | the tab order using <a href="qwidget.html#setTabOrder">QWidget::setTabOrder</a>(). (If you don't, Tab
|
|---|
| 76 | generally moves focus in the order of widget construction.) <a href="designer-manual.html">Qt Designer</a> provides a means of visually
|
|---|
| 77 | changing the tab order.
|
|---|
| 78 | <p> Since pressing Tab is so common, most widgets that can have focus
|
|---|
| 79 | should support tab focus. The major exception is widgets that are
|
|---|
| 80 | rarely used, and where there is some keyboard accelerator or error
|
|---|
| 81 | handler that moves the focus.
|
|---|
| 82 | <p> For example, in a data entry dialog, there might be a field that is
|
|---|
| 83 | only necessary in one per cent of all cases. In such a dialog, Tab
|
|---|
| 84 | could skip this field, and the dialog could use one of these
|
|---|
| 85 | mechanisms:
|
|---|
| 86 | <p> <ol type=1>
|
|---|
| 87 | <p> <li> If the program can determine whether the field is needed, it can
|
|---|
| 88 | move focus there when the user finishes entry and presses OK, or when
|
|---|
| 89 | the user presses Enter after finishing the other fields. Alternately,
|
|---|
| 90 | include the field in the tab order but disable it. Enable it if it
|
|---|
| 91 | becomes appropriate in view of what the user has set in the other
|
|---|
| 92 | fields.
|
|---|
| 93 | <p> <li> The label for the field can include a keyboard shortcut that moves
|
|---|
| 94 | focus to this field.
|
|---|
| 95 | <p> </ol>
|
|---|
| 96 | <p> Another exception to Tab support is text-entry widgets that must
|
|---|
| 97 | support the insertion of tabs; almost all text editors fall into this
|
|---|
| 98 | class. Qt treats Control+Tab as Tab and Control+Shift+Tab as
|
|---|
| 99 | Shift+Tab, and such widgets can reimplement <a href="qwidget.html#event">QWidget::event</a>() and
|
|---|
| 100 | handle Tab before calling <a href="qwidget.html#event">QWidget::event</a>() to get normal processing of
|
|---|
| 101 | all other keys. However, since some systems use Control+Tab for other
|
|---|
| 102 | purposes, and many users aren't aware of Control+Tab anyway, this
|
|---|
| 103 | isn't a complete solution.
|
|---|
| 104 | <p> <h3> The user clicks a widget.
|
|---|
| 105 | </h3>
|
|---|
| 106 | <a name="1-2"></a><p> This is perhaps even more common than pressing Tab on computers with a
|
|---|
| 107 | mouse or other pointing device.
|
|---|
| 108 | <p> Clicking to move the focus is slightly more powerful than Tab. While
|
|---|
| 109 | it moves the focus <em>to</em> a widget, for editor widgets it also moves
|
|---|
| 110 | the text cursor (the widget's internal focus) to the spot where the
|
|---|
| 111 | mouse is clicked.
|
|---|
| 112 | <p> Since it is so common and people are used to it, it's a good idea to
|
|---|
| 113 | support it for most widgets. However, there is also an important
|
|---|
| 114 | reason to avoid it: you may not want to remove focus from the widget
|
|---|
| 115 | where it was.
|
|---|
| 116 | <p> For example, in a word processor, when the user clicks the 'B' (bold)
|
|---|
| 117 | tool button, what should happen to the keyboard focus? Should it
|
|---|
| 118 | remain where it was, almost certainly in the editing widget, or should
|
|---|
| 119 | it move to the 'B' button?
|
|---|
| 120 | <p> We advise supporting click-to-focus for widgets that support text
|
|---|
| 121 | entry, and to avoid it for most widgets where a mouse click has a
|
|---|
| 122 | different effect. (For buttons, we also recommend adding a keyboard
|
|---|
| 123 | shortcut: <a href="qbutton.html">QButton</a> and its subclasses make this very easy.)
|
|---|
| 124 | <p> In Qt, only the <a href="qwidget.html#setFocusPolicy">QWidget::setFocusPolicy</a>() function affects
|
|---|
| 125 | click-to-focus.
|
|---|
| 126 | <p> <h3> The user presses a keyboard shortcut.
|
|---|
| 127 | </h3>
|
|---|
| 128 | <a name="1-3"></a><p> It's not unusual for keyboard shortcuts to move the focus. This can
|
|---|
| 129 | happen implicitly by opening modal dialogs, but also explicitly using
|
|---|
| 130 | focus accelerators such as those provided by <a href="qlabel.html#setBuddy">QLabel::setBuddy</a>(), <a href="qgroupbox.html">QGroupBox</a> and <a href="qtabbar.html">QTabBar</a>.
|
|---|
| 131 | <p> We advise supporting shortcut focus for all widgets that the user may
|
|---|
| 132 | want to jump to. For example, a tab dialog can have keyboard shortcuts
|
|---|
| 133 | for each of its pages, so the user can press e.g. Alt+P to step to the
|
|---|
| 134 | <u>P</u>rinting page. But don't overdo this: there are only a few
|
|---|
| 135 | keys, and it's also important to provide keyboard shortcuts for
|
|---|
| 136 | commands. Alt+P is also used for Paste, Play, Print and Print Here in
|
|---|
| 137 | the <a href="accelerators.html">standard list of shortcuts</a>, for
|
|---|
| 138 | example.
|
|---|
| 139 | <p> <h3> The user uses the mouse wheel.
|
|---|
| 140 | </h3>
|
|---|
| 141 | <a name="1-4"></a><p> On Microsoft Windows, mouse wheel usage is always handled by the
|
|---|
| 142 | widget that has keyboard focus. On Mac OS X and X11, it's handled by
|
|---|
| 143 | the widget that gets other mouse events.
|
|---|
| 144 | <p> The way Qt handles this platform difference is by letting widgets move
|
|---|
| 145 | the keyboard focus when the wheel is used. With the right focus policy
|
|---|
| 146 | on each widget, applications can work idiomatically correctly on
|
|---|
| 147 | Windows, Mac OS X, and X11.
|
|---|
| 148 | <p> <h3> The user moves the focus to this window.
|
|---|
| 149 | </h3>
|
|---|
| 150 | <a name="1-5"></a><p> In this situation the application must determine which widget within
|
|---|
| 151 | the window should receive the focus.
|
|---|
| 152 | <p> This can be simple: if the focus has been in this window before, then
|
|---|
| 153 | the last widget to have focus should regain it. Qt does this
|
|---|
| 154 | automatically.
|
|---|
| 155 | <p> If focus has never been in this window before and you know where focus
|
|---|
| 156 | should start out, call <a href="qwidget.html#setFocus">QWidget::setFocus</a>() on the widget which
|
|---|
| 157 | should receive focus before you <a href="qwidget.html#show">QWidget::show</a>() it. If you don't,
|
|---|
| 158 | Qt will pick a suitable widget.
|
|---|
| 159 | <p>
|
|---|
| 160 | <!-- eof -->
|
|---|
| 161 | <p><address><hr><div align=center>
|
|---|
| 162 | <table width=100% cellspacing=0 border=0><tr>
|
|---|
| 163 | <td>Copyright © 2007
|
|---|
| 164 | <a href="troll.html">Trolltech</a><td align=center><a href="trademarks.html">Trademarks</a>
|
|---|
| 165 | <td align=right><div align=right>Qt 3.3.8</div>
|
|---|
| 166 | </table></div></address></body>
|
|---|
| 167 | </html>
|
|---|
