I’ve been doing some refactoring lately meaning to improve overall maintainability of code (and hopefully even bring us into something close to ES6) and I’m feeling that combined (unexpanded) mode doesn’t really bring that much to the table to validate its continued existence.
For people who want to see a concise headlines list there’s classic multipanel mode, with optional widescreen layout. For people who want to scroll down (like myself) there’s combined (expanded) mode which has been the default for years now.
The fact that it’s a lump of ugly special case ancient code doesn’t help either. Anyway, if you’ve been using that one, say your farewells.
seems like all my problems relate to combined mode. i dropped that and it’s back close enough to what i had.
j/k switch between articles for sure and work correctly in this mode.
I’m really gonna miss this It hits me right in my most common workflow
Combined-collapsed (mark-read-on-scroll turned off) lets me read headlines and selected articles in the same flow, without wasting a ton of screen space on a pane that is generally empty (or only has old data.) I’ll admit to using it to mark stuff read that I’m not interested in (keyboard shortcuts ftw) but most of what I gather I want to read somewhere, just maybe not right now.
It uses the screen effectively to show the article while it is being read, instead of a cropped down viewport, then the article gets out of the way for the headlines.
I use that mode on anything that isn’t ultra-wide or ultra-small. (On my phone I’ve got an api-based web app, on my normal desktop I use 3-panel widescreeb.) Combined works great on tablets, laptops, normal monitors etc.
An always-on expanded view means a lot of scrolling in feeds with lots of updates, overview of the feed is totally gone, widescreen view just doesn’t work for me.
After updating all my images were back at max width, so after messing around with the new CSS I came up with the following updated code to use in the customize css pref function:
The two max-width items were the most important for what I wanted to accomplish (limiting image width and text block width) so you’ll want to adjust those to suit your preference.
I am by no means a CSS expert, so if anyone wants to recommend optimizations please do!
Update: I had a display: block item in the first section but that caused all the icons within post content to display one at a time vertically instead of side by side, so I removed it.
Update 2: display: inherit; seems to do the trick for fixing a image/text wrapping issue I was seeing with Engadget’s feed without disrupting things the way I was seeing with block.
No disrespect, I love Tiny Tiny RSS, this just killed the great user experience I’ve had for years for me personally. I guess I have to adapt, because, like I said, I love Tiny Tiny RSS.
Like others here, I liked unexpanded mode, it just seemed cleaner for me. That said, I can get over that, but one thing that doesn’t seem to be working properly in expanded mode is marking the last unread article of the feed read when using the keyboard. I suspect this will get tricky, because it seems to trigger the article being “read” when the article pane gets scrolled to the top of the feed list. However, using keyboard short cuts to scroll through the article doesn’t seem to push the article far enough down to trigger it as read.
Not sure the best way to handle it either, I mean, I could just press M and mark it as read manually, I guess, but that seems a bit clunky.
oh right this looks like a regression, i think in this case article should be marked as read when it is set active (by keyboard) which it doesn’t - i’ll take a look a bit later
Might be related, but if not, might as well throw this in too.
If you get to the end of a feed and do a shift+n to go to the next feed, pressing n again gets you to the first article, but it won’t let you keep going. Once you have started to scroll, the rest of the feed seems to work okay.
It hits me right in my most common workflow 
