Conversation
|
| } | ||
| } | ||
|
|
||
| Column { |
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
|
the most important option is missing : Open Channel |
|
@MD77MD no, it is still there, it was moved under the video name to save some space (it should be noticeable since it's colored in blue) |
|
Idea to make the "open channel" link more accessible: adding a tiny "open" icon like this one after the channel name |
ShareASmile
added
the
discussion
Stypox
force-pushed
the
long-press-menu
branch
2 times, most recently
from
80a12bd to
8b4be69
Compare
|
@MD77MD would an icon like this make it clearer? 
|
it does...but to tell you the truth, its not necessary. i was just too hasty ... collerd in blue is enough |
There was a problem hiding this comment.
I believe it'd be a good idea to introduce separate Stream and Playlist data classes, like how I've done here: #11947
That would remove the need to define multiple factory methods.
There was a problem hiding this comment.
Yeah that's a good idea. We should definitely have a data type for the UI layer that is independent of the types in the extractor or the database. I don't think I will do the change in this PR though, as it's already quite big. I'd rather first merge #11947 and then rebase on top of it (or the other way around).
Stypox
force-pushed
the
long-press-menu
branch
from
8883579 to
a898d75
Compare
Instead of overriding the whole showInfoItemDialog
... and add TODO comments for the `onDelete` implementations, which will be embeddable only after migrating the list fragments to Compose. Also remove incomplete and misleading toStreamInfoItem() implementations in StreamStatisticsEntry and PlaylistStreamEntry. Now one has to do statisticsEntry.streamEntry.toStreamInfoItem() instead, making it clear that the call only uses data from streamEntry.
Especially in and around LongPressAction.kt Also add some logging / Toast when fetchAllAndShuffle() has to stop early
Also add 2 tests to make sure all menu buttons are the same size Also simplify some code in LongPressMenu instantiation Also make the LongPressMenuEditor appear on top of the LongPressMenu instead of closing and reopening the LongPressMenu
Also improve some tests for LongPressMenu and add some test utility functions
Stypox
force-pushed
the
long-press-menu
branch
from
e752a2d to
34d4eae
Compare
The Work In Progress versions may still be considered useful in case of future changes though!
|
Ok, this PR is not fully ready for review and user feedback :-D
|
|
Thank you! |
Testing feedbackBugsThe menu is not restored on screen rotation: Screen_recording_20260213_112625.webm Stream that is already marked as watched can still be marked as wathched. You might want to disable that option if the stream is stored as watched (could ne done in a future PR). |
| Log.w(TAG, "Actions in settings were not distinct: $actions != $actionsDistinct") | ||
| } | ||
| return actionsDistinct | ||
| } catch (e: NoSuchElementException) { |
There was a problem hiding this comment.
Better variable name everywhere please
| } catch (e: NoSuchElementException) { | |
| } catch (exception: NoSuchElementException) { |
| } | ||
| } | ||
|
|
||
| @Preview(showBackground = true, backgroundColor = 0xFFFFFFFF) |
There was a problem hiding this comment.
is specifying background color necessary?
| val date = | ||
| Localization.relativeTimeOrTextual(context, stream.uploadDate, stream.textualUploadDate) | ||
|
|
||
| if (views.isEmpty()) { |
There was a problem hiding this comment.
Please use when wherever possible instead of if-else
| */ | ||
| @Composable | ||
| fun TooltipIconButton( | ||
| onClick: () -> Unit, |
There was a problem hiding this comment.
onClick can be made last parameter to allow better kotlin syntax when calling it
| .doOnError { throwable -> error = throwable } | ||
|
|
||
| fun toStreamInfoItem(): StreamInfoItem { | ||
| val item = StreamInfoItem(serviceId, url, title, streamType) |
There was a problem hiding this comment.
Just a suggestion but maybe we can simply return here with an apply to set other parameters instead of creating a new variable.
| /** | ||
| * Asserts that [value] is NOT in the range [[l], [r]] (both extremes included). | ||
| */ | ||
| fun <T : Comparable<T>> assertNotInRange(l: T, r: T, value: T) { |
There was a problem hiding this comment.
Better variable names please, for all the function parameters as well.
| /** | ||
| * Use this instead of passing contexts around in instrumented tests. | ||
| */ | ||
| val ctx: Context |
There was a problem hiding this comment.
Please prefer context and instrumentation instead
TobiGr
left a comment
TobiGr
left a comment
There was a problem hiding this comment.
Some of the new files do not have any SPDX license identifier headers. Please add them so that we can slowly make NewPipe REUSEable.
| // Note: this does a blocking I/O call to the database. Use coroutines when | ||
| // migrating to Kotlin/Compose instead. |
There was a problem hiding this comment.
So that is highlighted for the next person taking care of it :)
| // Note: this does a blocking I/O call to the database. Use coroutines when | |
| // migrating to Kotlin/Compose instead. | |
| // TODO: this does a blocking I/O call to the database. Use coroutines when | |
| // migrating to Kotlin/Compose instead. |
| LongPressable.fromPlaylistMetadataEntry(selectedItem), | ||
| LongPressAction.fromPlaylistMetadataEntry( | ||
| selectedItem, | ||
| // Note: this does a blocking I/O call to the database. Use coroutines when |
There was a problem hiding this comment.
| // Note: this does a blocking I/O call to the database. Use coroutines when | |
| // TODO: this does a blocking I/O call to the database. Use coroutines when |
| public ChannelTabPlayQueue(final int serviceId, | ||
| final ListLinkHandler linkHandler) { | ||
| this(serviceId, linkHandler, null, Collections.emptyList(), 0); |
There was a problem hiding this comment.
I'd also rename the ListLinkHandler to tabHandler to be consistent.
11 participants
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.
Update 11 Feb 2026: this PR is now fully ready for review!
Screenshots
Since I put a lot of effort into writing good documentation in the code, I won't extend the description here, but instead show some screenshots:
Motivation and design goals
Some of these points arose after some discussions in the NewPipe Matrix channel
TODO
TODO in future PRs
RouterActivitywith the long press menuFixes the following issue(s)
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