More suggestions related to playing audio attachments content

[pvagner]

Hello,
Thanks for all the hard work even during holiday.
This is related to my feature request #659 and related pull request #686.
I know this is not yet released to public however I've built it on my own and here's my feetback.
Recently I have added two posts that include audio attachments into my bookmarks.
When I open the side menu, press the bookmarks first post is visible as a whole and the second post is visible partially.
Each of these two posts includes single audio file attachment.
And both of the audio files start to play simultaneously right after I open the bookmarks screen.
I think it would be nicer if the audio player would start stopped and the playback should start after pressing the play button.

Additionally there is something for the discussion as I am not sure you will like to accept such a suggestion.
I am thinking the player should only display the single control the play button when scrolling the timeline. After the play button is pressed at least once it should expand to display other controls such as repeat, prev / next and the slider. When the timeline is being navigated with a screen reader I'd suggest to present as few clickable controls to screen readers as it remains very easy to navigate by posts. It's a continuation of the idea why most of the inline clickables are also implemented as an accessibility actions. Thanks for adding dislike action like that as well.

[AkesiSeli]

Thanks for the suggestions! That makes perfectly sense, I'll see how I can implement both of them.

[pvagner]

Hello,
Huge thanks for reworking this.
The play button and the fact it does not auto play is working fine. Unfortunatelly I have discovered more issues.

When the fakePlayer is being used with the play button only, I would also like to stop screen readers from focusing that disabled slider. Perhaps by just adding clearAndSetSemantics modifier into it.

And there is another issue with the player it-self that I haven't realized yesterday.
We are using .semantics(mergeDescendants = true) on the TimelineItem composable. That's supposed to merge non clickable non actionable controls into this composable for accessibility presentation. And the issue is that audio player's controls such as prev/ play/ next are also merged. The thing is these controls have no accessibility role, no actions so initially this looks like the player developers oversight to me. I have found out the player source code and I am trying to find out where the AudioPlayerComposable is implemented to verify this assumption.
https://github.com/Chaintech-Network/ComposeMultiplatformMediaPlayer

[AkesiSeli]

It is likely to be an oversight by the player library developers, as are the hard coded English content descriptions of the buttons. The good news is that the UI can be replicated completely if needed, the bad news is that it is a little extra work. If only we could find a compromise not to reimplement everything it would be better.

[pvagner]

I can't find where that AudioPlayerComposable is implemented. Can you please try to take a look as well?
Perhaps I can then try to report an issue to them and get it fixed eventually. I guess it might not be that difficult.

[AkesiSeli]

I did see the sources in android studio navigating to the library code, but I can't find it on GitHub either...

EDIT: I found the sources in this page, you can download the sources as a JAR from Maven (here).