The backlog of community suggested features is huge and I am slowly burning through it woohoo.
Full changelog
- Add support for featured posts on Piefed instances.
- Add setting to wrap comment headers if they are too wide. Default: on.
- Add setting to have “Hide read” on when the app is launched. Default: off.
- Add feature to highlight new comments. Can be enabled/disabled in settings. Default: On.
- Change default setting for FAB quick action: None -> Hide read.
- Fix some link parsing issues.
- Fix a bug where community is “reset” and position/sort order is lost when app is killed and recreated.
- Fix an issue where video players are not getting deallocated correctly.
- Fix a bug where the comments footer disappears if “show navigation bar on post” is enabled.
Thank you so much!
Thank you!
Sweet!
I’ve tried the “Hide read” option instead of trying the Lemmy setting of not enabling showing read posts (what a mouthful) and it’s extremely slow, especially when fetching Top x posts. After a long while Summit showed a message like “hid 8000 posts”.
Is Summit hiding them client side?
Wouldn’t it be better to use the
show_readandshow_hiddenfilters available on Lemmy’s/post/listendpoint?I’d really like to be able to quickly switch between seeing read posts or not seeing read posts.
Yep, it is client side. It might not work for all uses. It only normally hides at most 200 posts in my average use case. I can use the filter on the endpoint but they are more limited and interfere with other functions of the app.
I’ve had issues with this as well.
Yep, it is client side. It might not work for all uses. It only normally hides at most 200 posts in my average use case.
I don’t mind it being slow, but it might be nice to have an indicator that the app is still doing something in the background, and hasn’t frozen or crashed.
How does the app determine when enough posts have been hidden? Does it just hide the last 500 read posts, or does it keep hiding posts until it finds 50 unread posts?
Would it be possible to display any of this information to the user while the process is running?
It keeps hiding until there is enough for a page to be displayed. I don’t remember the size of a page on the top of my head. It’s probably 20. Also, I can definitely add a granular loader, it was just never requested by users in the past. The app shows a spinner so it should be obvious when loading, it just doesn’t show the exact details just because loading a page is pretty complex and it is only going to get more and more complicated as more features are added.
I can add a granular load animation to the roadmap.
Managing read and hidden messages on the client will result in many unnecessary calls to the server to retrieve posts that won’t be displayed. That’s especially bad for small underpowered servers or servers with many (Summit) users.
When the read posts are filtered out on the server side they do it already when retrieving them from the database. That is much easier on the resources and also means fewer data sent to clients, which should be good for people on metered connections.
The app allows you to use server side “hide read posts” so it doesn’t stop users from using the server-sided implementation. But, some features in the app do not work well this the server-sided implementation.
The trouble with the setting from Lemmy-Web is that you cannot toggle the hiding and showing on the fly. But they added that as dynamic filter options to the API a few versions ago. Those filters even work independent of what the user has set in Lemmy-Web.
So you could send those options over, depending on what the user has selected in Summit. And it will send exactly those posts over the user wants to see. And if the server is too old to support the filters they should just be ignored and Summit can fall back to its own implementation or what is selected in Lemmy-Web.
I honestly think they never should have let the Lemmy-Web option be saved on the server. It should have been UI-only. That is what has landed us in this mess in the first place. Hope they remove it with 1.0 because it’s just confusing.
Have you opened an issue on the GitHub?
There either was one or I opened it. Can’t remember. That’s how we got the filter options in the API.
Yeah I can add that in the next update





