Changing the Amount of Scroll by Arrow Key

This isn’t a bug report, but a question.

The up and down arrow keys scroll about half a page of text for me. I’d like to change this to 2-5 lines of text instead, to be consistent with other websites where I scroll using the arrow keys. What’s the magic incantation I can stick in the custom user CSS to make this happen?

Thanks!

as far as i remember, after the last scrolling overhaul up/down scrolling is passed directly to browser now, so we unfortunately can’t control it at all.

e: i might be wrong though

this.hotkey_actions["article_scroll_down"] = function (event) {
                  const ctr = App.isCombinedMode() ? $("headlines-frame") : $("content-insert");

                  if (ctr)
                     Article.scroll(ctr.offsetHeight / 2, event);
               };

you can try changing that to / 3 etc

I don’t know if I’m doing this wrong, but this didn’t work for me. I am using Combined mode, not in wide screen. It’s interesting you note that all of this is in the hands of the browser now. Other websites are giving the 2-4 lines of text scrolling behavior. Is this “issue” related to dojo? I don’t think it’s anything wrong with TT-RSS itself (that it scrolls a half page) but perhaps the framework that TT-RSS is leveraging to handle arrow key scrolling?

Here’s the entire content of CSS customizations:

.cdm .content-inner {
    font-family: "Segoe UI", Ubuntu, "Helvetica Neue", Helvetica, Arial, sans-serif;
    font-size: 16px;
}

this.hotkey_actions["article_scroll_down"] = function (event) {
    const ctr = App.isCombinedMode() ? $("headlines-frame") : $("content-insert");
    if (ctr)
        Article.scroll(ctr.offsetHeight / 2, event);
};

yeah that was me being wrong. i’ll try take a look at this in more detail later today.

e: however, maybe out of the box up/down should be passed on to browser, the only thing that would make sense to do is focus content panel first if it isn’t.

this way we have fast switching to articles with n/p (or any other configured hotkeys) and native scrolling with up/down or mousewheel.

this way this rather ugly scrolling code which will always behave different to how browser does it may be removed altogether.

to add, the above might make some sense in combined mode but in three panel mode removing up/arrow handlers is just stupid imo, they fit the UI too well.

that’s native scrolling. you can have that if you unbind down/up arrows entirely.

this comes with downsides like focusing the element to scroll manually (with your mouse), etc. as far as i remember, focusing things with hotkeys is not reliable so you can’t just make a bunch of hotkeys to focus various UI parts.

which means we have to either forgo arrows entirely or implement hacks.

that aside, i agree that up/down specifically should probably scroll based on something approaching a few lines of text, not pages, closer to native scrolling (which we won’t be able to replicate).

the way it works now is basically legacy behavior from previous “maybe move to next or previous article or one third of a viewport” thing we had going for last few years.

how about this? i’m not committing this yet to master but i think it makes a bit more sense.

arrow_scrolling.diff (2.5 KB)

  • up/down in combined mode moves stuff closer to native scroll (height may need to be adjusted further)
  • pgup/pgdown work as before, i.e. not handled by tt-rss

article container-specific keys:

  • shift up/down move in a similar way, i.e. by a few lines of text
  • shift pgup/pgdown move by an almost entire page up/down

i’m not particularly happy with the scrolling code (it’s too convoluted) and i wish i could just send some kind of page down event to an element and it would scroll down natively but it seems impossible (?) for security reasons.

with this change at least up & down don’t behave as half-pgup and half-pgdown which isn’t really a thing in any UI.

updated WIP diff: arrow_scrolling_v3.diff (10.8 KB)

this rebinds N/P hotkeys to move by pages instead of lines (shift+up/down moves content by lines).

this also fixes inconsistent handling of articles when up and down keys are pressed in combined mode

I upgraded to commit 19893d3.

I can not figure out if this is intended or not, but I noticed that, in combined mode, using CTRL+Down, there is an inconsistent behavior in feeds with short articles.
If I select the feed, multiple articles are presented on the right pane. Scrolling down mark them read. Once the last visible one is read, they all scroll up and the next unread ones are shown.

This becomes uncomfortable because I can no longer keep my eyes on the first and have TT-RSS “updating” the unread ones for me. I have to look through all the page and then go back to the top again once the page is refreshed.

If the behavior is as intended, is there a workaround in order to have TT-RSS keep the latest unread article on top, no matter how long it is?

Thank you very much in advance

EDIT Re-reading this, I am not sure if I was clear enough.
Take for example the register’s feed
If I select just this feed from the feed tree, between 4 and 5 unread articles are shown on the right pane in combined mode. It does not matter if I use keyboard n or Ctrl+Down: all the articles are progressively marked as read and kept in the right pane, without any scrolling, until the last one is reached. then all the read ones disappear and a new batch is shown.

yep, buffer is scrolled or article is repositioned if there’s not enough space to show it without doing so. that’s going back to how this worked several years ago.

if you want to always show next/previous article on top, i’ve added special option to Headlines.move() to mimic this behavior which could be used as a custom keybind.

I guess a plugin would be needed, right?

a very simple one.

instead of adding another bunch of hotkey actions - which would quickly become a terrible idea if more permutations are added - i’ve added two default fields to Headlines object:

https://git.tt-rss.org/fox/tt-rss/commit/b39e615683dae2d9b08939b7fb131cb8607c8415

a plugin might set those on init and then stock hotkeys would “just work”.

i’m sure someone here would be able to make a plugin for that in a few minutes, hl_legacy can serve as an almost complete example, i.e.

require(['dojo/_base/kernel', 'dojo/ready'], function  (dojo, ready) {
	ready(function() {
		Headlines.default_force_to_top = true;
	});
});

Thanks for the reply. Unfortunately, I do not have any knowledge, so I hope someone will come up with a plugin.

On a more general level, I checked all the already existing keyboard’s related plugins, and those are the ones that I could find:

  • googlereaderkeys
  • hotkeys_noscroll
  • swap_jk
  • keyboard_cursor
  • minimal_hotkeys
  • quick_unsubscribe
  • toggle_night_mode
  • rodneys_hotkeys

It seems to me there is a huge need for users to configure their experience using TT-RSS.
I totally get it that you do not want to over complicate things, but would you consider adding a tab in “Preferences” that could allow anyone to customize the keyboard mapping?

a plugin might add an entire hotkey editor, it’s just that making the UI takes more effort so you have the above instead.

i don’t really want to bother with this but if someone else does, I’ll review the PR.