Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request]: Keyboard shortcuts to scroll through content #1151

Open
1 task done
Pottit opened this issue Oct 8, 2024 · 2 comments
Open
1 task done

[Request]: Keyboard shortcuts to scroll through content #1151

Pottit opened this issue Oct 8, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@Pottit
Copy link

Pottit commented Oct 8, 2024

Describe the request

One of my favourite features of Phanpy is the ability to scroll through posts using the keyboard. The mapping is something like the following:

J: Next post
K: Previous post
L: Like post

It makes it very easy to scroll through the timeline and like posts. It is even responsive to keyboard layouts, so on my Dvorok layout it responds to HTN instead of JKL.

I see in #199 that there's a preference not to use regular keys to perform functions, which of course is a valid concern; but how about for example ↓ or → to select the next post, and ↑ or ← for the previous post? I'm not sure what would be an intuitive shortcut for favourite in this set-up, but it would make for comfortable scrolling. :)

A lynx-style approach could also be taken, where → opens a posts and ← goes back again, while ↑ and ↓ navigate the feed.

Implementation Details

@Pottit Pottit added the enhancement New feature or request label Oct 8, 2024
@GeopJr
Copy link
Owner

GeopJr commented Oct 8, 2024

↓ or → to select the next post, and ↑ or ← for the previous post?

That's already the case. Gtk will attempt to focus on the sibling in the pressed arrow key direction:

Screencast.From.2024-10-08.12-14-20.mp4

but it's based on focus, aka you need to be focused on the posts list to navigate that and similarly for the sidebar.

L: Like post

-1 from me. Too easy to trigger, especially without modifiers.

@Pottit
Copy link
Author

Pottit commented Oct 8, 2024

↓ or → to select the next post, and ↑ or ← for the previous post?

That's already the case. Gtk will attempt to focus on the sibling in the pressed arrow key direction:

You're right - this already goes a long way.

I did not realize this while testing, possibly because it can easily get lost. The following steps disabled navigation through arrow keys:

  1. Select a post (not a boost)
  2. Press [->] twice

The focus is now on the name of the author, and it cannot be removed (as far as I can see) without pressing the Home button using the mouse. (Edit: Tab does the trick - but this is still not particularly intuitive)

Ideally when pressing [->] on a post, the user should maybe be allowed to interact with attachments, content warnings, and respond/boost/share/bookmark, rather than to the profile pictures. I still believe opening a post on [->] and closing it on [<-] could be an intuitive behaviour.

There are some other behaviours that could be tweaked - for example, if the posts loose focus, the selected post will always be the first in the timeline rather than the one currently visible on screen. I don't know if this can be fixed, and this might not be the right place for that anyway.

L: Like post

-1 from me. Too easy to trigger, especially without modifiers.

I don't think it's that common to randomly press buttons when a window is open, though I understand the reasoning. At least got me, scrolling through elements with J and K (or the buttons in these positions) has been the preferred behaviour of pretty much any software since Google reader, and I know I'm far from alone in that regard. Modifiers would defeat the purpose, as the accessibility of these buttons is the whole rationale behind the behaviour.

In either case it's a great piece of software - thank you so much for your work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants