1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Qt Toolkit - Keyboard Focus Overview</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: white; color: black; }
--></style></head><body bgcolor="#ffffff">
<p>
<table width="100%">
<tr><td><a href="index.html">
<img width="100" height="100" src="qtlogo.png"
alt="Home" border="0"><img width="100"
height="100" src="face.png" alt="Home" border="0">
</a><td valign=top><div align=right><img src="dochead.png" width="472" height="27"><br>
<a href="classes.html"><b>Classes</b></a>
-<a href="annotated.html">Annotated</a>
- <a href="hierarchy.html">Tree</a>
-<a href="functions.html">Functions</a>
-<a href="index.html">Home</a>
-<a href="topicals.html"><b>Structure</b></a>
</div>
</table>
<h1 align=center> Keyboard Focus Overview</h1><br clear="all">
Keyboard focus, like much else on the human end of a GUI, tends to be
full of exceptions and not at all neat.
<p>
The basic problem is that the user's keystrokes can be directed at any
of several windows on the screen, and any of several widgets inside
the intended window. The user presses a key, wishing it to go to the
right place. The window system is responsible for directing the
keystroke to the window the user wishes, the application running that
window for directing each keystroke to the widget the user wishes. Of
course the user's wish moves at whim.
<p>
The application's responsibilities is the subject of this page.
<p>
<h2>Focus motion</h2>
<p>
There are, historically, a few ways in which the user directs the
keyboard focus at a desired widget: <ol>
<li> The user presses Tab (or Shift-Tab) (or sometimes Enter).
<li> The user clicks a widget.
<li> The user presses a keyboard shortcut.
<li> The user uses the mouse wheel.
<li> The user moves the focus to this window, and the application has
to guess to which widget.
<p>
</ol>
<p>
Each of these motion mechanisms is different, and different types of
widgets receive focus in only some of them. We'll cover each of them
in turn.
<p>
<h2>Tab/Shift-Tab.</h2>
<p>
Pressing Tab is by far the most common way to move focus using the
keyboard. Sometimes in data-entry applications Enter does the same as
Tab. We will ignore that for the moment.
<p>
Tab, in all window systems in common use today, moves the keyboard
focus to the next widget in a circular per-window list. Tab moves
focus along the circular list in one direction, Shift-Tab in the
other. The order in which Tab moves is called the tab order.
<p>
In Qt, this list is kept in the <a href="qfocusdata.html">QFocusData</a> class. There is one
QFocusData object per window, and widgets automatically append
themselves to the end of it when <a href="qwidget.html#f92b0f">QWidget::setFocusPolicy()</a> is
called with an appropriate <a href="qwidget.html#FocusPolicy">QWidget::FocusPolicy</a>. You can customize
the tab order using <a href="qwidget.html#20c984">QWidget::setTabOrder()</a>. (If you don't, Tab
generally moves focus in the order of widget construction.)
<p>
Since pressing Tab is so common, most widgets that can have focus
should support tab focus. The major exception is widgets that are
only seldom used, and where there is some keyboard accelerator or
error handler that moves the focus.
<p>
For example, in a data entry dialog, there might be a field that is
only necessary in one per cent of all cases. In such a dialog, Tab
could skip this field, and the dialog could use one of these two
mechanisms: <ul>
<li> If the program can determine whether the field is needed, it can
move focus there when the user finishes entry and presses Ok, or when
the user presses Enter after finishing the other fields.
<li> The label for the field can include a keyboard shortcut that
moves focus to this field.
<p>
</ul>
<p>
There is also another exception to Tab support is text-entry widgets
that must support tab; almost all text editors fall into this class.
Qt treats Control-Tab as Tab and Control-Shift-Tab as Shift-Tab, and
such widgets can reimplement <a href="qwidget.html#6ff658">QWidget::event()</a> and handle Tab before
calling QWidget::event() to get normal processing of all other keys.
However, since some systems use Control-Tab for other purposes, and
many users aren't aware of Control-Tab anyway, this isn't a complete
solution.
<p>
<h2>The user clicks a widget.</h2>
<p>
This is perhaps even more common than pressing Tab on computers with a
good mouse or other pointing device.
<p>
Clicking to move the focus is slightly more powerful than Tab. While
it moves the focus <em>to</em> a widget, for editor widgets it also moves
the text cursor (the widget's internal focus) to the spot where the
mouse is clicked.
<p>
Since it is so common, it's a good idea to support it for most
widgets. People are used to it. However, there is also an important
reason to avoid it: You may not want to remove focus from the widget
where it was.
<p>
For example, in a word processor, when the user clicks the 'B'
(boldface) tool button, what should happen to the keyboard focus?
Should it remain where it was, almost certainly in the editing widget,
or should it move to the 'B' button?
<p>
We advise supporting click-to-focus for widgets that support text
entry, and to avoid it for most widgets where a mouse click has a
different effect. (For buttons, we also recommend adding a keyboard
shortcut - <a href="qbutton.html">QButton</a> and its subclasses make that very easy.)
<p>
For widgets that don't fall into either class, we have no advice.
<p>
In Qt, only the <a href="qwidget.html#f92b0f">QWidget::setFocusPolicy()</a> function affects
click-to-focus.
<p>
<h2>The user presses a keyboard shortcut.</h2>
<p>
It's not unusual for keyboard shortcuts to move the focus. This can
happen implicitly by opening modal dialogs, but also explicitly using
focus accelerators such as are provided by <a href="qlabel.html#085fdb">QLabel::setBuddy()</a>, <a href="qgroupbox.html">QGroupBox</a> and <a href="qtabbar.html">QTabBar</a>.
<p>
We advise supporting shortcut focus for all widgets that the user may
want to jump to. For example, a tab dialog can have keyboard
shortcuts for each of its pages, so the user can press e.g. Alt-P to
step to the <u>P</u>rinting page. But don't overdo this - there are
only a few keys, and it's also important to provide keyboard shortcuts
for commands. Alt-P is also used for Paste, Play, Print and Print Here
in the <a href="accelerators.html">standard list of shortcuts,</a> for
example.
<p>
<h2>The user uses the mouse wheel.</h2>
<p>
On Microsoft Windows, mouse wheel usage is always handled by the
widget that has keyboard focus. On X11, it's handled by the widget
that get other mouse events.
<p>
The way Qt handles this platform difference is by letting widgets move
the keyboard focus when the wheel is used. With the right focus
policy on each widget, applications can work idiomatically correctly
on both Windows and X11.
<p>
<h2>The user moves the focus to this window.</h2>
<p>
(and the application has to guess to which widget).
<p>
This can be simple: If the focus has been in this window before, then
the last widget to have focus should regain it. Qt does that
automatically.
<p>
If focus has never been in this window before and you know where focus
should start out, call <a href="qwidget.html#25775a">QWidget::setFocus()</a> on that widget before
you <a href="qwidget.html#200ee5">QWidget::show()</a> it. If you don't, Qt will pick some suitable
widget.
<p><address><hr><div align="center">
<table width="100%" cellspacing="0" border="0"><tr>
<td>Copyright 2001 Trolltech<td><a href="http://www.trolltech.com/trademarks.html">Trademarks</a>
<td align="right"><div align="right">Qt version 2.3.2</div>
</table></div></address></body></html>
|
