https://bugs.kde.org/show_bug.cgi?id=469215
Bug ID: 469215
Summary: Changes to focusReason are not handled after FocusIn
or FocusOut events
Classification: Frameworks and Libraries
Product: frameworks-qqc2-desktop-style
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kdelibs-b...@kde.org
Reporter: m...@ratijas.tk
CC: ahiems...@heimr.nl, k...@davidedmundson.co.uk,
noaha...@gmail.com, notm...@gmail.com
Target Milestone: ---
Created attachment 158586
--> https://bugs.kde.org/attachment.cgi?id=158586&action=edit
test.qml
SUMMARY
tl;dr KQuickStyleItem does not watch for changes to focusReason, in case it is
set after focus is already set or lost.
In QtQuick every Item type has focus and activeFocusOnTab properties; but
Controls also do have focusReason status and visualFocus derived from it. For
keyboard interactions it is common to set TabFocusReason on the receiving
control and BacktabFocusReason on the previously active. However, some
technical limitations such as https://bugreports.qt.io/browse/QTBUG-97006 might
force developers to resort to workarounds like setting ListView's current index
(thereby making some other item the currentItem and giving it activeFocus) and
then setting focusReason manually (also note that invoking forceActiveFocus()
won't change the reason as it short-circuits because an item is already
focused):
contentItem: ListView {
// Roll out custom key navigation because built-in one sets wrong
focusReason.
keyNavigationEnabled: false
delegate: QQC2.Button {
Keys.onDownPressed: {
ListView.view.incrementCurrentIndex();
ListView.view.currentItem.focusReason = Qt.TabFocusReason;
}
Keys.onUpPressed: {
ListView.view.decrementCurrentIndex();
ListView.view.currentItem.focusReason = Qt.TabFocusReason;
}
}
}
It works fine for Plasma controls and for any pure QML custom styling, but not
for qqc2-desktop-style bridge item, because this:
bool KQuickStyleItem::eventFilter(QObject *watched, QEvent *event)
{
if (watched == m_control) {
if (event->type() == QEvent::FocusIn || event->type() ==
QEvent::FocusOut) {
QFocusEvent *fe = static_cast<QFocusEvent *>(event);
m_lastFocusReason = fe->reason();
}
this is the only place where `m_lastFocusReason` is updated. Hence, changing it
after FocusIn even at runtime won't have any effect on the appearance of a
control.
STEPS TO REPRODUCE
0. export QT_QUICK_CONTROLS_STYLE=org.kde.desktop
1. Open this snippet (also available as an attachment) with qml or qmlscene:
https://invent.kde.org/frameworks/qqc2-desktop-style/-/snippets/2633
2. Navigate using Tab and Shift+Tab keys.
3. Navigate using Up/Down arrows.
OBSERVED RESULT
Buttons have nice highlighted outline when receiving focus via Tab, but not via
Up/Down keys.
EXPECTED RESULT
Focus highlight outline effect should applied regardless whether focusReason
was set at the time of FocusIn event or at some point later.
SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: git/5.27
KDE Frameworks Version: git/kf5
Qt Version: 5.15.9
--
You are receiving this mail because:
You are watching all bug changes.
