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.
  • Björn@swg-empire.de
    link
    fedilink
    arrow-up
    2
    ·
    3 months ago

    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_read and show_hidden filters available on Lemmy’s /post/list endpoint?

    I’d really like to be able to quickly switch between seeing read posts or not seeing read posts.

    • idunnololz@lemmy.worldOPM
      link
      fedilink
      arrow-up
      4
      ·
      3 months ago

      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.

      • threelonmusketeers@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        2
        ·
        3 months ago

        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?

        • idunnololz@lemmy.worldOPM
          link
          fedilink
          arrow-up
          3
          ·
          3 months ago

          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.

      • Björn@swg-empire.de
        link
        fedilink
        arrow-up
        1
        ·
        3 months ago

        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.

        • idunnololz@lemmy.worldOPM
          link
          fedilink
          arrow-up
          3
          ·
          3 months ago

          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.

          • Björn@swg-empire.de
            link
            fedilink
            arrow-up
            2
            ·
            3 months ago

            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.