Redesigned long press menu #12032
Redesigned long press menu #12032
Conversation
Implement content preview
|
| } | ||
| } | ||
|
|
||
| Column { |
There was a problem hiding this comment.
FlowRow could be used here instead.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
The linked documentation mentions a maxItemsInEachRow attribute.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Sure, but what's bad about using BoxWithConstraints and measuring the actual available space?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
|
I suggest something like this: 
the idea of a more button is to trigger a second bottom sheet containing the remaining items. |
|
@NaN-Sz thanks for the feedback! We already thought of the More button but the bottom sheet dialog already has kind of a way to show more buttons when there are too many (i.e. the menu starts out partially expanded, and you can scroll up to see the other buttons). What do you think about that? Also, do you think the buttons are too small in my screenshots? Your mockup has much bigger ones, that's why I'm asking. I find the buttons in my screenshots easy to press correctly but it's arguable. Maybe we could put a slider in the "long-press menu's settings menu" to pick a size for buttons. This would be quite a niche setting, but also easy to understand what it does (and we would put it only in the "long-press menu's settings menu", not in the app's settings). |
yes, it's actually better to scroll up than to use a button.
Your buttons are a good size. But bigger buttons are easier to see and more intuitive. Having too many small buttons makes the interface look cluttered.
I like the idea of customizing the app, I think it's a good idea. |
|
or maybe like this? 
|
|
These are really good changes to the UI 🚀 I tested this on two devices and personally think that four columns are ok. The less columns we have, the more vertical space is required and thus the actions aren't within the "thumb-radius" anymore. However, it might be necessary to test this on small devices and potentially use three columns on those smaller screens. I'd also suggest to not show more than three rows of actions by default on the smaller screens. It does not help people to find the stuff they need if their whole screens is plastered with action buttons. I'd vote in favour of the option to expand the bottom sheep by pulling it up which is quite intuitive. I do not think there is a need for a more button. |
|
Would it be a good idea to make it like only 3 or 4 most used options come on long press (delete, add to playlist, share, background ,etc). And then could be swiped up to show this all like it is. This will reduce vertical space. A cherry on cake will be if there's a customize option to chose which options should come on long press and all other in swipe up menu. |
ShareASmile
added
feature request
What is it?
Description of the changes in your PR
This PR replaces
InfoItemDialogwith 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.
Motivation and design goals
Some of these points arose after some discussions in the NewPipe Matrix channel
TODO
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