Redesigned long press menu

[Stypox]

What is it?

• [ x ] Feature (user facing)
• [ x ] Codebase improvement (dev facing)

Description of the changes in your PR

This PR replaces InfoItemDialog with a JetpackCompose-based bottom sheet menu. This new menu is supposed to replace all item long press menus across the app, i.e. streams, playlists, channels. The menu contains more details than before about the stream/playlist/channel that was clicked, laid out in a (imo) nice design.

Please provide feedback both on the code and on the UI, but please keep in mind the points below when suggesting an alternative layout. Note that the order of buttons is not yet finalized, and that at the moment the menu only works for streams.

Portrait	Landscape/tablet

Motivation and design goals

• A text-based menu is difficult to read and only allows for a handful of actions, while an icon-based menu is more compact and also easier to use. There still are some labels to explain what the actions do though.
• The menu puts the most frequent actions always in the same places, so muscle memory can help perform press the buttons faster.
• Users keep asking for new long press menu actions, therefore the long press actions system should be easily extendable and the set of actions should possibly even be editable by the user.
• We want to provide the same experience across the app (hence same menu for streams, playlists, channels), which also deduplicates a lot of code.
• A menu at the bottom of the screen is easier to use in one-handed mode.
• The menu adapts well to different screen sizes, e.g. by showing more/less buttons or adapting the header with item information.

^{Some of these points arose after some discussions in the NewPipe Matrix channel}

TODO

• Also use the dialog for playlists and channels
• Perform asynchronous stuff with coroutines instead of RxJava3
• Implement "Start playing from here" actions
• Handle Kodi action
• Decide whether to allow the user to customize the menu (there is already a mini settings button in the top right of the menu for that purpose, but now it doesn't do anything)
• Various other TODOs spread out in code
• Understand which issues are solved by this PR
• Add documentation
• Add UI tests (?)

APK testing

The APK can be found by going to the "Checks" tab below the title. On the left pane, click on "CI", scroll down to "artifacts" and click "app" to download the zip file which contains the debug APK of this PR. You can find more info and a video demonstration on this wiki page.

Due diligence

• [ x ] I read the contribution guidelines.

[sonarqubecloud]

Quality Gate passed

Issues
18 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Isira-Seneviratne]

FlowRow could be used here instead.

[Stypox]

Mmmh, that's what I was using in the beginning, but I don't think you can have a FlowRow with a maximum amount of items per row, but also have an item that weighs more than the others (i.e. the header). Also, I wanted the buttons to expand as much as possible, to not waste any space.

[Isira-Seneviratne]

The linked documentation mentions a maxItemsInEachRow attribute.

[Stypox]

I know, but I need the header to be counted as if it were 4 items. And then if more items can fit alongside the header, I need those to be aligned well. If you want to give it a try with FlowRow go ahead, but I couldn't make it do what I want.

[Isira-Seneviratne]

I was able to make the needed changes using FlowRow (it might need to be tweaked a bit).

Could you grant write access? I can't push the commit to this branch.

[Stypox]

Mmmh, I should have given you write access to the NewPipe repository (or maybe you had it already), which should be enough according to what GitHub says:

[...] users with write access to TeamNewPipe/NewPipe can add new commits to your long-press-menu branch.

Anyways, thank you for the patch! I haven't tested it yet (will do tomorrow) but from a brief look it seems like the fact that the header is always 66% of the width means the buttons in the first row won't be aligned like the ones below. Also, the buttons should fill as much horizontal space as possible, so misclicks can still be caught, and there might also be more space for the button label text. One final (minor) thing is that I wanted the layout to scale well just based on the available space, not specifically based on whether the device is landscape or portrait, so the header sizing in your patch does not fulfill this requirement.

[Isira-Seneviratne]

One final (minor) thing is that I wanted the layout to scale well just based on the available space, not specifically based on whether the device is landscape or portrait, so the header sizing in your patch does not fulfill this requirement.

That can be implemented using currentWindowAdaptiveInfo().windowSizeClass, like in the determineItemViewMode() method.

[Stypox]

Sure, but what's bad about using BoxWithConstraints and measuring the actual available space?

[Isira-Seneviratne]

Good point, though using it results in the IDE checking if the constraints are actually used. Also, it results in a lot more complexity than using FlowRow.

[Stypox]

You are right that it is indeed much more complex, so we might want to change the requirements. In the meantime I will add more documentation on the requirements (so people reading the code know why it was made like that).