Keyboard Focus in QMLWhen a key is pressed or released, a key event is generated and delivered to the focused QML Item. To facilitate the construction of reusable components and to address some of the cases unique to fluid user interfaces, the QML items add a scope based extension to Qt's traditional keyboard focus model. Key Handling OverviewWhen the user presses or releases a key, the following occurs:
See also the Keys attached property and KeyNavigation attached property. Querying the Active Focus ItemWhether or not an Item has active focus can be queried through the property Item::activeFocus. For example, here we have a Text element whose text is determined by whether or not it has active focus. Text { text: activeFocus ? "I have active focus!" : "I do not have active focus" } Acquiring Focus and Focus ScopesAn Item requests focus by setting the Item::focus property to true. For very simple cases simply setting the Item::focus property is sometimes sufficient. If we run the following example with the QML Viewer, we see that the keyHandler element has active focus and pressing the 'A', 'B' or 'C' keys modifies the text appropriately.
However, were the above example to be used as a self-contained component, this simple use of the Item::focus property is no longer sufficient. The left hand side of the following table shows what we would like to be able to write. Here we create two instances of our previously defined component, and set the second one to have focus. The intention is that when the A, B, or C keys are pressed, the second of the two components receives the event and responds accordingly.
The right hand side of the example shows the expanded code - the equivalent QML without the use of the component MyWidget. From this, the problem is evident - there are no less than three elements that have the Item::focus property set to true. Ultimately only one element can have keyboard focus, and the system has to decide which on. In this case the first appearance of the Item::focus property being set to true on line 4 is selected, and the value of Item::focus in the other two instances is reverted back to false. This is exactly the opposite of what was wanted! This problem is fundamentally one of visibility. The MyWidget components each set their keyHandler Items as focused as that is all they can do - they don't know how they are going to be used, but they do know that when they're in use their keyHandler element is what needs focus. Likewise the code that uses the two MyWidgets sets the second MyWidget as focused. While it doesn't know exactly how the MyWidget is implemented, it knows that it wants the second one to be focused. This allows us to achieve encapsulation, allowing each widget to focus on it's appropriate behaviour itself. To solve this problem - allowing components to care about what they know about and ignore everything else - the QML items introduce a concept known as a focus scope. For existing Qt users, a focus scope is like an automatic focus proxy. A focus scope is created using the FocusScope element. In the next example, a FocusScope is added to the component, and the visual result shown.
Conceptually focus scopes are quite simple.
So far the example has the second component statically selected. It is trivial now to extend this component to make it clickable, and add it to the original application. We still set a one of the widgets as focused by default, but from then on clicking the either one gives it focus.
When a QML item explicitly relinquishes focus (by setting its Item::focus property to false while it has active focus), the system does not automatically select another element to receive focus. That is, it is possible for there to be no currently active focus. See the Keyboard Focus example for a demonstration of moving keyboard focus between multiple areas using FocusScope elements. Advanced uses of Focus ScopesFocus scopes allow focus to allocation to be easily partitioned. Several QML items use it to this effect. ListView, for example, is itself a focus scope. Generally this isn't noticeable as ListView doesn't usually have manually added visual children. By being a focus scope, ListView can focus the current list item without worrying about how that will effect the rest of the application. This allows the current item delegate to react to key presses. This contrived example shows how this works. Pressing the Return key will print the name of the current list item.
While the example is simple, there's a lot going on behind the scenes. Whenever the current item changes, the ListView sets the delegate's Item::focus property. As the ListView is a focus scope, this doesn't effect the rest of the application. However, if the ListView itself has active focus this causes the delegate itself to receive active focus. In this example, the root element of the delegate is also a focus scope, which in turn gives active focus to the Text element that actually performs the work of handling the Return key. All of the QML view classes, such as PathView and GridView, behave in a similar manner to allow key handling in their respective delegates. X
|
Попытка перевода Qt документации. Если есть желание присоединиться, или если есть замечания или пожелания, то заходите на форум: Перевод Qt документации на русский язык... Люди внесшие вклад в перевод: Команда переводчиков |