Collections widgets should scroll with Home/End/Page Up/Page Down when focused

[m-rei]

Checklist

• [X] I have searched the issue tracker for open issues that relate to the same problem, before opening a new one.
• [X] This issue only relates to a single bug. I will open new issues for any other problems.

Describe the bug

Cant scroll with the keys specified in the title inside the list collection within the fyne demo!

How to reproduce

Open fyne demo, go to Collections -> List and try to scroll using one of the 4 keys.

Screenshots

No response

Example code

There is no code.

Fyne version

2.4.0

Go compiler version

1.21.7

Operating system and version

Fedora 39

Additional Information

Should work in all containers.

[dweymouth]

This is something that can't be really implemented automatically but would have to be done by your app. The reason is, unless something is focused, key events will reach the window canvas itself, where you can attach a key handler (SetOnTypedKey) and do whatever you want with events.

The collection widgets (list, gridwrap, tree, table) can be traversed with arrow keys once an item has been focused with the tab key.

Implementing the keyboard scrolling in your app is just adding a window-level key event handler and calling the various Scroll APIs on your desired list/gridwrap/table/etc in response to the appropriate key events. GridWrap has a ScrollToOffset and GetScrollOffset APIs available which can scroll the widget by arbitrary offsets, and it's planned to be added for at least List as well in Fyne 2.5.

[m-rei]

This is something that can't be really implemented automatically but would have to be done by your app. The reason is, unless something is focused, key events will reach the window canvas itself, where you can attach a key handler (SetOnTypedKey) and do whatever you want with events.

Every other app has this behavior, so i doubt it cant be done. The container was focused, the arrow keys work!

There should be default behaviors registered for all controls, invisible to the developers (end users). For example the scroll wheel works. How come? The event is propagated all the way down to the right component in the tree and the component reacts to the event. This propagation should happen for the key down events as well, so that you can implement default behaviors in the selected component. I don't have to implement that as an end user of the library, I don't have to implement text input and scrolling, why do I have to implement scrolling with those four specific keys?

I could do it easily, yes, but I should not have to.

When I use a scrolling container in the angular framework, I do not have to implement this default behavior myself. It just works as expected.

[dweymouth]

The scroll wheel works because which widget it goes to is based on the position of the cursor. With keyboard scrolling, consider an app that has two list views side by side. If neither is focused, which one should be scrolled by the keyboard? I think you may be used to the web app paradigm where the main view is always a "page" which is often scrollable. Desktop UIs don't necessarily adopt that paradigm.

That being said, if the app does have just a single scrollable view in its main layout, the developer should connect up the keyboard scrolling (I've recently done it in my app). But I'm not sure the toolkit itself can make that assumption for you.

[m-rei]

With keyboard scrolling, consider an app that has two list views side by side. If neither is focused, which one should be scrolled by the keyboard?

You keep coming back to the problem of not having focus.

In the example you give, it obviously cant work, but as soon as the user has interacted with one of the components, it should work. The engine should keep track of the last component the user interacted with. If its a container and the user presses the PageUp key, the container is supposed to scroll up. When the container does not behave this way, it appears unpolished. I dont understand why I have to defend this argument, you should agree.

I think you may be used to the web app paradigm where the main view is always a "page" which is often scrollable. Desktop UIs don't necessarily adopt that paradigm.

Counter example: Intellij IDE. I have two scrolling containers: the main code container and the project structure tree view on the side. Both scroll with page up/down keys, when they have focus. The entire GUI is not a scrollable page. It contains scrollable components.

Decades ago I implemented a custom opengl GUI library in pascal. You simply internally keep track of the last focused component, which receives those events. Im not too familiar with the fyne architecture, whether this can be done as I imagine it, but there surely must be a way. I dont want to get into it, but if all fails, I may take a look and create a PR...

[dweymouth]

Would it satisfy your feature request for the collection widgets (List, GridWrap, Tree, and Table) to respond to Home/End/PageUp/PageDown when focused? That could be easily added as it fits within the current architecture. Having a collection widget scroll with the keyboard when not focused would be more of a breaking change and would need discussion amongst the contributors of how to design an API/redesign the internals to support it.

[m-rei]

Would it satisfy your feature request for the collection widgets (List, GridWrap, Tree, and Table) to respond to Home/End/PageUp/PageDown when focused? That could be easily added as it fits within the current architecture

Yes.

Having a collection widget scroll with the keyboard when not focused would be more of a breaking change and would need discussion amongst the contributors of how to design an API/redesign the internals to support it.

When not focused, it can not be decided which container should scroll (as you have made clear with your example in your previous comment), if you have multiple containers. It would lead to confusion.

I would not implement something like that. I am not even asking for something like that.

[dweymouth]

Ah, I misunderstood your original request then. We can certainly get around to adding those key bindings to the focused collection widgets. (And if you'd like to make a PR we can provide guidance ;)

[m-rei]

And if you'd like to make a PR we can provide guidance

Yes, would be nice. I have implemented it for the List widget already. Table, Tree and GridWrap are pending. Would need a bit of help with the test cases, unless there are similar test which I can copy and adjust.

Where can we talk - discord?

[dweymouth]

There is the Fyne discord, but most contributor conversations happen in the #fyne-contributors channel in the Gophers slack.

[dweymouth]

You can also open a draft PR for discussion