I was dissatisfied with the way moving between articles worked, especially after implementing smooth scrolling it became apparent how sometimes scrolling sometimes jumping to an article may be disorienting.
Additionally, it was too easy to trigger a situation where going to a previous/next article directly would select something entirely unexpected because of active article tracking.
I’ve implemented some changes to how this works in trunk here and I’m interested in feedback, i think this makes overall scroll/move behavior more predictable.
I just updated to the latest trunk (5b4eb8d7b) and noticed that articles are suddenly automatically marked as read when scrolling using the mouse wheel.
I checked the settings and the “Mark read on scroll” option is still disabled.
this means we’re back to no tracking of active article on scroll unless auto mark as read is enabled so if you’re using mouse to scroll you’ll have to select something explicitly for next/previous hotkeys to work, otherwise you’re starting from the beginning. so, back to clumsy previous behavior there.
maybe in this situation (scroll offset > 0, n or p is pressed) ttrss should start from first visible article and go from there. note that this would mark it as read.
this may not technically be the logical behavior but i think this is the one a user would actually want.
i.e. select something, scroll way down using the mouse, press N to move to next article, list goes back up. because that’s where your previous selection was. technically correct but stupid.
I’m on 985e11b75 and in combined mode, when I press n, it simply scrolls the panel down, it doesn’t open the next article, which is what it did previously. The space bar here does the same thing…am I missing another setting that I may need to correct after this update?
read the commit message which explains everything in detail, also (as before) there are separate hotkeys which always move between articles (ctrl+up/down), n/p always worked a bit differently out of the box in combined mode.
also, imagine i probated you for a month for not reading anything before posting.
Sorry, I missed that in the commit message.
It might not be a bad idea to update the behavior in the Keyboard Shortcuts help, since the n/p still indicates that they move to the next article.
Wow, this is rather jarring. After the latest git pull I thought I’d broken something. That is a huge UI change. I usually always just j,k,n,p to navigate tt-rss; occasionally I scroll forward or backward to get to an article and I don’t want auto-read marking turned on. Now nothing gets marked read at all. : /
Can the old functionality be provided via a plugin?
it is a rather big change but i think it’s justified. i never liked this hybrid “move to article or maybe scroll down” even though i used it a lot; because things jumping around while you read instead of going at constant speed is imo disorienting.
as with smooth scrolling i’m sure we can figure out a compromise solution here though.
there’s a stock plugin that sets n/p to their noscroll “classic” variants, maybe that is what you want? then you can move between articles with n/p and scroll article content with a separate hotkey.
i don’t really understand this. not wanting auto mark as read is useful when you pick and choose your articles to read, so you might have legit unread things above the viewport.
this fits well with three panel mode because you have all your headlines as a glance and you can move between them without opening the article.
on the other hand, if you open a feed in combined mode and start pressing n what you’re functionally accomplishing is marking things as read while you scroll, the only difference is that you’re using the keyboard – and yet you don’t want to enable the option which does the exact same thing but also with a mouse wheel. why?
e: there might be some merit in rebinding n/p to noscroll hotkeys out of the box, while keeping arrow hotkeys as they are. it makes some sense that pressing down would scroll things down but n goes to a next article. this is not going to restore the hybrid approach though but i hope i’ve already explained why i feel it is flawed.
It did behave strangely at times, especially towards the end of an article, that is true.
Thanks, I’ll check it out.
I don’t use 3 panel mode, in combined mode scrolling forward to an article marks all in between read. I guess it is time to give 3 panel mode another try.
I use combined mode / two panel and 'j,k (Swap j and k hotkeys plugin enabled) and ‘n,p’ to navigate. I’ve tried three panel in the past, it doesn’t work for me. Anyway.
The ‘n’ functionality is back. That’s good, but the now ‘p’ functionality for me does not work as expected. Previously, I could click on a feed in the categories left pane, get the list of new articles, then press ‘p’ and the bottom (oldest) article text would open in the right pane. Not now.
Now instead, when ‘p’ is pressed, the top (newest) article opens, just as if I had press ‘n’. The only way I can open the oldest first in the list of articles is to mouse click the oldest article. After that I can navigate with ‘p’ as expected.
Would it be possible to get the previously ‘p’ keypress functionality back? I.e., ‘p’ opens the oldest article in a list of articles, instead of the newest as it does presently.
I’ve tried this p,n navigation in a couple of different browsers including the latest chromium-browser in incognito mode (as I type). Same functionality in all.
yeah, honestly i don’t understand why this was there in the first place. i think main reason is that i didn’t figure out what p should do when no article is selected when i was first implementing this many years ago.
tell me, what would be the point of ever starting from the bottom of currently loaded headline block? you’re going to trigger lazy load, etc.
if you want to read oldest first just sort the list this way and go from the beginning.
if no article is open, it goes from the currently visible one, regardless of direction chosen.
why? main problem with old behavior was losing context when current article is somewhere far away because you scrolled past it or there was no article selected.
you press p and list suddenly scrolls a few pages down, potentially marking everything as read as it goes if you have that enabled. the whole thing was a shitpile, frankly.
I didn’t use ‘p’ to open articles with a massive amount of text so this was never an issue (for me, at least). But I see where it could be so point taken.
Yes, thought of that too. I’ve enable the ‘feedprefs’ plugin in case I find a reoccurring situation where oldest first seems best for a particular feed.
Yes, I get it now.
=====
fox, thanks for all the time and effort you put into this project.
.
I preferred the legacy n functionality. I used j k n as a compact single hand set of controls where:
j - top of next article
k - top of previous article
n - scroll down a percentage of the screen or to the top of the next article if the top of the next article is already visible.
n was very handy if an article that is longer than the screen. Yes the space bar provides partial functional overlap but I personally miss the old ‘n’ functionality. It just worked.
… I guess it is time to give 3 panel mode another try.
I just can’t get used to 3 panel mode, but collapsed mode works well enough with the new ui scrolling settings. What I miss is when Shift+n/p scrolled “a little” instead of 1/2 the page. I already have a custom plugin where I have personal preference hotkey bindings; I added a binding to the spacebar to scroll 1/8th the screen. Or, for me, about 4 lines. That helps me transition to the new behavior a lot.