Better keyboard navigation

[mrixner]

• I have read the contributing guidelines, and I agree with the Code of Conduct.
• Have you checked that there aren't other open pull requests for the same changes?
• Have you tested that the committed code can be executed without errors?
• This PR is not composed of garbage changes used to farm GitHub activity to enter potential Crypto AirDrops.
  Any user suspected of farming GitHub activity with crypto purposes will get banned. Submitting broken code wastes the contributors' time, who have to spend their free time reviewing, fixing, and testing code that does not even compile breaks other features, or does not introduce any useful changes. I appreciate your understanding.

---

This pull request allows typing in a package list view to jump to that package, much like how Windows Explorer allows you to type out a file name on your keyboard outside of the search bar to jump directly to the file.

I tried to solve #1217 but I couldn't get SelectedIndex and such to work, so I ended up using FilteredPackage.IndexOf(PackageList.SelectedItem) and then after all of that apparently the Select call doesn't actually select the element and pressing enter would open the package details for the previously selected element, which I don't know how to fix (or even what the problem is). It occurs to me that this affects this code as well, but the main purpose is to focus the element on the screen.

[marticliment]

I tried to solve #1217 but I couldn't get SelectedIndex and such to work, so I ended up using FilteredPackage.IndexOf(PackageList.SelectedItem)

You can fix this by using the Index property of the PackageWrapper items that come from the ObservablePackageCollection structure (AbstractPackagesPage.FilteredPackages), instead of finding the package on the list (with still would work but wouldn't be as efficient.)

I think #1217 is more of a limitation with how ItemsView handles item focus by default. In fact, after pressing a package on the list arrow navigation works.

Perhaps I could implement arrow press detection, and if the user presses an arrow key and no item is selected the first/last item could be manually selected and then focus given to the package list, so it feels more like the Windows explorer. If you want, I can do this.

[mrixner]

You can fix this by using the Index property of the PackageWrapper items that come from the ObservablePackageCollection structure (AbstractPackagesPage.FilteredPackages), instead of finding the package on the list (with still would work but wouldn't be as efficient.)

Ahh, OK. Done, thanks.

I think #1217 is more of a limitation with how ItemsView handles item focus by default. In fact, after pressing a package on the list arrow navigation works.

Yeah, I noticed this. #1217 was, I think, primarily about making it loop back around, but I've also noticed that occasionally using the arrow keys moves the ListView, not the focused element.

Perhaps I could implement arrow press detection, and if the user presses an arrow key and no item is selected the first/last item could be manually selected and then focus given to the package list, so it feels more like the Windows explorer. If you want, I can do this.

Yeah, this isn't that hard; fixed in 1d1ee33.

I think the two solutions to making the keyboard navigation actually useful is that SelectAndScrollTo needs to put the focus on the selected element, which I couldn't figure out how to do, or PackageItemContainer_KeyUp (AbstractPackagesPage.xaml.cs:907) needs to use the SelectedItem instead of the sender.

There are also a whole lot of Select calls in the abstract packages page (for example, when an element is right clicked) that if this focus thing gets fixed I would recommend updating as well, because when something looks focused (as happens when Select is called) it should be enterable.

[marticliment]

I think the two solutions to making the keyboard navigation actually useful is that SelectAndScrollTo needs to put the focus on the selected element, which I couldn't figure out how to do, or PackageItemContainer_KeyUp (AbstractPackagesPage.xaml.cs:907) needs to use the SelectedItem instead of the sender.

I don't think the second is possible, do you think that forcing focus on the ItemsView on SelectAnScrollTo could fix the issue?

[mrixner]

I don't think the second is possible, do you think that forcing focus on the ItemsView on SelectAnScrollTo could fix the issue?

Yeah, I'm pretty sure the problem is that while the item is selected, the focused item doesn't change, and the focused item is the one sending the event.

[mrixner]

Correction: forcing focus on the ItemsView wouldn't work, the focus has to be on the element being selected.

[marticliment]

I am then afraid that this issue cannot be fixed by a limitation on WinUI

[mrixner]

Ahh, that's unfortunate. I would've really appreciated this :( I suppose I should remove the arrow key code then, since it doesn't make much sense to a) hinder the default behavior and b) have arrow key selection that doesn't actually allow enter-for-package details. Is my assessment correct?

[mrixner]

I don't think the second is possible

Could I ask why not? Does the Sender expose something SelectedItem doesn't? Or is it better practice?

[marticliment]

Could I ask why not? Does the Sender expose something SelectedItem doesn't? Or is it better practice

Tested it twice and didn't succeed. the sender object seems to be unreliable when using lists with dynamic containers. Or at least when I tried I couldn't get them to work.

[marticliment]

I have been testing the code, and I have observed the following behaviour:
Pressing multiple times the same key does not iterate over packages starting with the same key (it should do that if the goal is to mimic windows explorer). Instead, it jumps to a random package. Let me give details:

1. Press letter b. Package BDlot DVD master gets highlighted (as expected).
2. Press letter b (again). Instead of Beaker being selected, Anki gets selected, which is not even the first package that starts with letter a.
3. Pressing the letter b more times will remain on Anki being selected.

[marticliment]

Issue mentioned on the PR conversation

[mrixner]

Anki is probably being selected because it's ID has a bb in it? I noticed this in explorer the other day but I didn't even know that was the functionality before lol... I'll go fix it.

[marticliment]

Anki is probably being selected because it's ID has a bb in it?

No, it's id is Anki.Anki

[mrixner]

Well that's really bizarre then, I can't imagine why that would be.

[marticliment]

Please mark the conversation as resolved when you can fix the issue, thanks!

[mrixner]

I've made it so pressing the same key cycles through the items starting with that letter. I'll mark the review as resolved but I would like you to make sure it doesn't select Anki.Anki again or some other weird behavior. Thanks!

[mrixner]

Please mark the conversation as resolved when you can fix the issue, thanks!

Uhh... I'm not sure how...