https://bugs.kde.org/show_bug.cgi?id=526205
Bug ID: 526205
Summary: People view: arrow-key navigation does not auto scroll
as it should do in the thumbnail view while a "face
scan" is running - reproducible.
Classification: Applications
Product: digikam
Version First 9.1.0
Reported In:
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: Faces-Workflow
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 196526
--> https://bugs.kde.org/attachment.cgi?id=196526&action=edit
Proposed patch: keep keyboard focus visible in People view during face scans
(against v9.1.0, not yet compiled)
DESCRIPTION
In the People view (a person, Unknown or Unconfirmed selected, where faces
normally are shown as thumbnails), moving the current focused item with the
arrow keys, with or without Shift being held down, moves the focus and
selection correctly, however the view does not scroll to keep the focus in
view. It should follow it while a face scan is running, but it does not. The
focused face is allowed to go off screen, and I have to use the mouse to drag
the scroll bar down and find it again. With no face scan running, scrolling
auto follows the focus as expected.
STEPS TO REPRODUCE
1. Settings > Configure digiKam > Miscellaneous > Behavior: "Enable background
face recognition scan" on (or start any face scan).
2. Open People and select a person or Unknown with more faces than fit on
screen.
3. Confirm one face so that a face scan starts (it shows in the status bar
progress area).
4. Click the first face, then press Down (or Shift+Down) repeatedly.
OBSERVED RESULT
The selection moves below the visible area; the view does not scroll.
EXPECTED RESULT
The view keeps the current item visible, as it does when no scan is running and
in album views.
CAUSE (from reading the 9.1.0 source)
DigikamItemView::scrollTo() (core/app/items/views/digikamitemview.cpp) returns
early whenever the view is in People icon mode and any face-scan task is
registered with the ProgressManager. The comment says this stops the view
jumping while a scan adds or removes faces (bugs 444692 and 440232; 440232
looks like an unrelated Kirigami bug). The check also swallows the scrollTo()
that Qt calls from currentChanged() during keyboard navigation. With background
recognition on, a scan restarts after every confirmed face, so in practice the
People view rarely follows the keyboard during a review session.
MY SUGGESTED FIX (patch attached, not yet compiled)
Override keyPressEvent() in DigikamItemView and set a flag for the duration of
the base handler (QScopedValueRollback); scrollTo() skips the early return
while the flag is set. Scrolls caused by model changes during a scan stay
suppressed (keeps the bug 444692 fix); arrow and Shift+arrow will scroll again.
And looking at the related bugs - I found bug 457896. It's the same symptom
that was fixed back in 2022 except while a face scan runs, and background
recognition now makes that most of the time. it is that link that is what keeps
this from being closed as "by design".
SOFTWARE/OS VERSIONS
digiKam 9.1.0 (Windows installer), Windows 11 64-bit, MariaDB 12.2 database.
--
You are receiving this mail because:
You are watching all bug changes.
