Scrolling with arrow keys

[Magnus26]

Issue type

UX/Interaction bug (incorrect behaviour)

Description with steps to reproduce

1. Open the dialog window Settings (Edit -> Settings).
2. Press Shift+Tab to move the selection frame to the category list to the left.
3. Press DownArrow until Shortcuts is selected.
4. Press Tab three times to move the selection frame to the list of shortcuts to the right.
5. Press and hold DownArrow until the last list item is reached.
6. Press DownArrow again and look what happens. The expected would be that either nothing happens because the last item is reached or that the selection frame is moved to the first item in the list, but instead it is moved just a bit up the list and from there it is impossible to move further up with UpArrow. One can't with the arrow keys get out of this little loop of list items.

Supporting files, videos and screenshots

What is the latest version of MuseScore Studio where this issue is present?

4.4.1

Regression

I was unable to check

Operating system

Q4OS

Additional context

No response

Checklist

• [X] This report follows the guidelines for reporting bugs and issues
• [X] I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
• [X] I have attached all requested files and information to this report
• [X] I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

[cbjeukendrup]

Related to #22179.

The problem here is that QML automatically deletes list items that are not inside the viewport; and that means they won't be visible to the keyboard navigation anymore.

[Magnus26]

Related to #22179.

The problem here is that QML automatically deletes list items that are not inside the viewport; and that means they won't be visible to the keyboard navigation anymore.

Is it QML that has to be fixed?

[cbjeukendrup]

It's not really a bug in QML, just a consequence of how QML does this. We'll need to 'work around it'.

[Magnus26]

It's not really a bug in QML, just a consequence of how QML does this. We'll need to 'work around it'.

What is the purpose of QML doing this?

[cbjeukendrup]

Reducing memory usage, by not unnecessarily rendering items that are currently not visible (in long lists, there may be thousands of those, so this is a very significant optimisation.

[Magnus26]

[...] so this is a very significant optimisation.

I have never before seen this behaviour in any program. Is the memory usage critical in this case?

[cbjeukendrup]

Not much more critical than in other UI applications. Possible reasons that you haven't seen such behaviour before:

• QML apps are not that common (at least, I don't know any, other than MuseScore, and in Dorico small parts of the UI are done in QML)
• In most QML apps, you won't notice that this is happening because they use a different keyboard navigation system. MuseScore uses a custom one, because QML's default system is not flexible enough for us.

[rpatters1]

I would just like to add that I have encountered something similar while working on #24509. I hope that whatever solution it is will be a general solution for StyledListView.

[Magnus26]

I have just discovered that PageUp and PageDown function like Up and Down instead of as expected jumping to the top or bottom of the list view.

[cbjeukendrup]

PageUp/Down issues are covered by https://github.com/musescore/MuseScore/issues/24513 (Also, they are not expected to jump to the top or bottom, because that's what Home and End do, but they should scroll by the amount of pixels of the viewport height.)

[Magnus26]

PageUp/Down issues are covered by #24513 (Also, they are not expected to jump to the top or bottom, because that's what Home and End do, but they should scroll by the amount of pixels of the viewport height.)

OK, good. (Yes, that is what I meant with "list view" instead of writing only "list". "Viewport" is a new term to me.)