this post was submitted on 17 Feb 2025
16 points (100.0% liked)

Summit

801 readers
9 users here now

Community to discuss Summit, a Lemmy reader for Android.

App (Play Store): https://play.google.com/store/apps/details?id=com.idunnololz.summit

APK: https://github.com/idunnololz/summit-for-lemmy/releases

Support the app

Support me on Patreon

Website: https://summit.idunnololz.com/

founded 2 years ago
MODERATORS
idunnololz@lemmy.world
16
[WIP][v1.55.0] Fulfilling more user requests (lemmy.world)
submitted 6 days ago* (last edited 4 days ago) by idunnololz@lemmy.world to c/summit@lemmy.world
9 comments fedilink hide all child comments
 

User request roadmap items are growing pretty long so this release aims to address a bunch of them.

Changes so far

  • Add a setting to disable auto-linking IP addresses. Note that auto-linking IP addresses comes free with Android so enabling this feature will actually cause the app to strip them which is a bit slower.
  • Add a new layout: full with cards. This layout is the full layout but each post is contained within a card instead of full bleed.
  • Changed the UI for the post feed toolbar.
  • Fixed a bug where sometimes expanding the context in the message screen would cause weird behavior.
  • Fix locales being mixed together. (Attempt number 2)

Update

One of the roadmap items I am tackling is the addition of an optional post feed header. This one is challenging for a few reasons. The first is that because it's supposed to be optional, the UI design needs to work with or without the headed. The second is that there's a lot of moving parts with headers when the screen is this busy and complex already.

To tackle the first part I am redesigning the tool bar in the post feed screen so it will look good with or without the header.

you are viewing a single comment's thread
view the rest of the comments
[–] idunnololz@lemmy.world 1 points 6 hours ago* (last edited 6 hours ago)

Ok I just realizes there are some even more edge cases. Consider the following actions:

  1. User watches a video in the past in full screen mode and mutes the video. The app remembers this.
  2. User scrolls the post feed to an inline video.
  3. Video players but is muted by default.
  4. User unmutes the video.
  5. User taps to watch the video full screen.

Now what should happen?

Option 1. the video plays full screen but now it is muted because the app remembers from the previous session that full screen videos should play muted.

Option 2. the video plays with the same volume as when it was inline. The app remembers the volume so when the next video is played full screen it will be played with the same volume.

I think in this option 2 should happen. I think to resolve all of these edge cases it's probably easier to consider the inline and full screen players as different "apps" with their own different states.

Inline should always obey one set of rules and full screen should always obey a different set of rules UNLESS an inline player is expanded. In the case where an inline player is expanded, the full screen player should take the settings from the inline player and also persist those settings.