Navigation with arrow keys

[kimmustcode]

suggestion to add ability to navigate through previews with with the arrow keys

[sinbadthepoet]

Read over the contributor's guide, would like to work on this issue. It's a bit of an older one so I'm not sure if it'll be seen, but we'll see.

Current plan is to replicate the behavior of the Windows Explorer. Left and right advance the selection index, wrapping to the appropriate row when pressing against the edge of a row if another row is available. Up and down would increase or decrease the selection index by the row width. Pressing up or down when at the end of a column would do nothing. I have noticed one exception to this in windows, pressing down at the bottom of a column when there is a row below. This happens when items wrap to a new row, without there being enough items to fill that row completely.

Here's an example of what I mean:

In the event where there are multiple selections, pressing an arrow should make a new singular selection based on the position of the last selected selection.

Below, I have a multiselection in Windows Explorer. The lighter box is the item last added to the selection. Pressing right moves the selection to the second image.

Lastly, holding shift while pressing an arrow key create a multi selection similar to a shift click. I believe the existing shift click code should be usable.

This is my first code contribution to an open source project, so I would appreciate feedback and help on my proposal. From what I have gathered, it seems like I will need to add code to /src/qt/ts_qt.py specifically to the QtDriver class. We use frame_content to get the item ids, and can gather the next or previous (right and left) ids by finding the position of the current item in selected (if selected is only 1 item, otherwise the last element of selected). I would need to figure out how to find the row width, it seems likely it has something to do with the flow_container. Once row width is found, it should be trivial to match the behavior of windows, simply checking to make sure that the new index wouldn't be out of range. The special case of moving the selection from above an incomplete row (As seen in the first pair of images) likely wouldn't be so elegant, needing to check for a specific case by referencing the row numbers and determining the positions of the current selection and the final element of the set. With this being the case, feel free to let me know if there is a better solution or if this functionality should just be ignored. I personally don't feel it in incredibly relevant.

I'm not experienced with Qt, so learning to set all this up will be new. My plan is to create one function that subscribes to each of the four arrow key press events. It checks to see which key was pressed, and then uses the toggle_item_selection function to make the selection, enabling bridge if the shift is held down. The biggest question to figure out before I begin implementation is how to subscribe to key press events, and if I can determine which key press triggered the function without creating multiple different functions.

Let me know if I did anything critically wrong!

[CyanVoxel]

Your outline of the feature seems perfect! This is exactly how I'd expect the arrow navigation to work in the thumbnail grid.

---

For the specifics of the implementation, I can help point you in the right direction when it comes to our own code however I'm also not a Qt expert. From my quick attempts at doing something like this myself in the past, I've tried to override the keyPressEvent() methods in one or more of the item_thumb classes to try and intercept the arrow keys. I've used this for intercepting other keys in the past but there's something about the arrow keys that Qt specifically has a problem with letting me intercept. Otherwise it works something like this (example from tag_search.py):

@override
def keyPressEvent(self, event: QtGui.QKeyEvent) -> None:  # noqa N802
    # When Escape is pressed, focus back on the search box.
    # If focus is already on the search box, close the modal.
    if event.key() == QtCore.Qt.Key.Key_Escape:
        if self.search_field.hasFocus():
            return super().keyPressEvent(event)
        else:
            self.search_field.setFocus()
            self.search_field.selectAll()

That being said, Qt has some secret sauce for keyboard navigation that might be able to be leveraged. Something adjacent to this is the TabOrder which we've been using more in places such as build_tag.py to set the navigation order when tabbing between widgets. Not quite the same as what's going on here, but I mention it to demonstrate a little bit about some non-obvious inner workings of Qt's keyboard navigation system.

A phenomenon I've also noticed when working on the TagColorSelection modal is that I think Qt has some way of knowing the positions of widgets on the screen and can use that as part of an arrow key navigation flow. This can be demonstrated when using the Tag Color Selection modal, selecting one of the color swatches (which are just radio buttons) and then using the arrow keys to move to adjacent swatches. The crazy thing is that these radio buttons are part of different widgets with separate flow layouts, but somehow Qt is putting together how to navigate between them with the arrow keys. I'm not sure if that's something that can be leveraged here, but in any case I thought I'd mention it.

[sinbadthepoet]

Getting back to this pretty late, but hoping to crunch this out today since I have time. What about creating a set of QActions for each arrow key, leaving them unparented from the menu bars, and just adding shortcuts for them? Gonna try this out to see if it works, but shooting this here just to get the go ahead that that's something that would be acceptable.