-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't go directly to fullscreen when tapping thumbnail #4152
Comments
Was it possible before? I can't reproduce in 0.19.8, please give steps to reproduce. Btw, isn't it a duplicate of #4070? |
I did give STR: "(for those checking: requires locked system rotation and landscape mode in main player)"
That's the issue I was browsing when I remembered I wanted to open this one. That one is for external links. This one is for the thumbnail in video details. |
I think this is a good idea. It feels more natural to open the video upon clicking the thumbnail, than opening a info page from where you can start the video. It feels more natural (maybe just because it's what youtube does). |
@EliasKomar This issue is for the thumbnail you see in the video details page, not for thumbnails in video lists like search results, playlists, etc. If you want the video to autoplay upon opening like Youtube does, then that's the default behaviour in the upcoming unified player. @B0pol Sorry, this comment made me realise I didn't specify where the thumbnail was, which led to your questions. I'll edit the OP. |
If the fullscreen opened when tapping the thumbnail, it would be an inconsistent and possibly unexpected behaviour with respect to how the video starts playing with autoplay enabled. But at the same time I think the benefits outcome the cons, so I agree this should be changed. @avently what do you think? |
Well, yeah. You can only see the thumbnail when autoplay is off. Otherwise, when autoplay is on, the video is already playing and it's one tap to go full screen. If autoplay is off, it's two taps: one to play the video in portrait mode, and another to go full screen. |
I think it's a bad idea. We already discussed it in the unified PR:
You probably didn't see how it looks like but I did. I use this for more than 1 year long. I added this "mode" just because theScrabi asked about it in my first PR here. I'm ok if it will be optional and disabled by default but even in this case I will never write any line of code for this "anti-feature". Yeah, it may sound unpleasant but it's how I feel like when I remember this ugly transition from portrait to landscape on every play. I just use autorotation enabled globally and the only thing I need to do is to rotate the phone for viewing on fullscreen. |
@avently Are you talking about the transition that exists in 0.19.8? Or was yours different in someway? |
I'm talking about transition that takes place after clicking on fuillscreen button. If the feature you want will be realized than the same action will be made after a stream starts playing. And this is bad in terms of usability. If you want the rotation happens just press on the fullscreen button. It's ok because you really expect that the screen rotates. |
Yes, that's what happens in 0.19.8 and all the releases before it, and it's the behaviour I'm used to. Since the autoplay option didn't exist before, it wasn't a problem. But now that it does, this should be a setting, dependent on the autoplay one. So if autoplay is on, this setting should be greyed out. But I'm concerned about this:
Are you talking about bugs appearing elsewhere because of this code change? |
No, it will not produce any bugs, it's just a couple of lines of code but it doesn't look logical choice to rotate the screen after pressing on thumbnail. |
Ah well, it would be behind a toggle, so those who don't want it can avoid it. |
Guys, when do you plan to release 0.20.0? Looks like some PR should be merged and we are done? |
Please make it an opt in and disable it by default. |
You are talking about fullscreen after play, it can be easily implemented but the problem I see is when the device is in portrait mode. So what do you expect to happen after play when your device is in portrait and horizontal video started to play? Automatic action can only be made when you have global autorotation disabled (I.e. locked to portrait or landscape). And a part of the question, what should happen when you stopped watching the video (I.e. video finished or you pressed back button)? What do you expect to see when the global autorotation is enabled? The problem is these questions I don't have universal answers for. Because some people would want one behavior, another people want other behavior. From my point of view, the app shouldn't go into fullscreen when the rotation is not appropriate for the video. For example, when the device in portrait (with locked orientation) playing horizontal video in fullscreen should only be possible after automatic rotation to landscape. Same for vertical videos: fullscreen should only be possible when device already rotated or rotated automatically to portrait. The autorotation i'm talking about is already implemented (on phones) and you can test how it works in playlists with mixed horizontal and vertical videos: in locked orientation in fullscreen your phone will be rotated to different orientations appropriate for a video orientation. |
I personaply prefer this(do note that in comment above I said it should be
opt-in and disabled by default):
I click on the video, its video info shows with autoplay turned off, I
again click on it, it stars playing fullscreen+landscape(irrespective of
phone rotation) , When I click back it should go back to portrait(phone'
rotation) and show video info.
(To be fair I hate video info too, it wastes time and one unnecessary click
gets added)
Anyways it is my personal preference and that is why I think it should be
made configurable in settings(and disabled by default).
I will try(try being a key word) to submit a PR for the same this week.
…On Mon 5 Oct, 2020, 4:36 PM avently, ***@***.***> wrote:
You are talking about fullscreen after play, it can be easily implemented
but the problem I see is when the device is in portrait mode. So what do
you expect to happen after play when your device is in portrait and
horizontal video started to play?
• device stays in the same orientation but opens on fullscreen
• device switches to landscape and opens in fullscreen?
Automatic action can only be made when you have global autorotation
disabled (I.e. locked to portrait or landscape).
And a part of the question, what should happen when you stopped watching
the video (I.e. video finished or you pressed back button)?
What do you expect to see when the global autorotation is enabled?
• device should go into fullscreen
• nothing should happen?
The problem is these questions I don't have universal answers for. Because
some people would want one behavior, another people want other behavior.
From my point of view, the app shouldn't go into fullscreen when the
rotation is not appropriate for the video. For example, when the device in
portrait (with locked orientation) playing horizontal video in fullscreen
should only be possible after automatic rotation to landscape. Same for
vertical videos: fullscreen should only be possible when device already
rotated or rotated automatically to portrait. The autorotation i'm talking
about is already implemented (on phones) and you can test how it works in
playlists with mixed horizontal and vertical videos: in locked orientation
in fullscreen your phone will be rotated to different orientations
appropriate for a video orientation.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4152 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALIG6OWVEPJX7NICBCQVP4LSJGSCFANCNFSM4QBTJU6A>
.
|
@avently The automatic fullscreening behaviour doesn't need to change from the current one at all. Pretend that the feature is implemented such that after the user taps the thumbnail to play, the app immediately auto-taps the full screen button. That's it. Whatever behaviour the app has currently, can continue to be so. The full screen button should behave as it does now.
Personally, I think the player should remain in fullscreen and wait for the user to tap Back to go back to video details. But this can be tested properly only after the basic auto-full screen behaviour is in place. So it doesn't need to be part of the initial commit/effort. We'll get more knowledge about what looks good or bad when we have an apk to test.
Nothing should change there, I think. Because full screen is a function of rotating the phone in that case, it shouldn't change anything in the current behaviour. No extra tap required there like it is in locked orientation.
🤭 We only need auto full screen for portrait mode. The app automatically goes into full screen if you tap the thumbnail in locked landscape rotation. |
I'm finding this new behaviour incredibly irritating: First, on my Amazon Fire 5th Gen, even in landscape it doesn't automatically play fullscreen, the video starts playing on the details page. Second, I never want a video to play on the details page (no, not even on the YT website) - all that does is shrink the video. The only instance I would want anything other than fullscreen video or background audio is splitscreen with another app. Which isn't handled by NewPipe (and already worked fine on my phone anyway), so isn't relevant. I definitely want an option to toggle the old behaviour (I doubt "always play as if the fullscreen button was hit" would be hard. Automatic autoplay was bad enough, but at least that has a toggle...)
It's not "ugly", it's practical. I keep my phone locked in portrait mode for everything except video because I don't want it rotating on me if I'm, say, lying in bed. If I'm reading, I want it in portrait near-100% of the time, and I spend more time reading than watching video. All you're doing by removing this as even a choice is adding "friction" in the form of extra clicks - while the video is playing, to boot. Removing something which clearly some people prefer, even if the ostensible replacement was bug free (it isn't, it's broken on my Fire which is locked in landscape) is my definition of an "anti-feature". |
I agree fully with @sanityormadness . The use case "watching video in bed" is a large one for me, and also an important reason why I have auto rotate off. The autoplay can fortunately be switched off, but if this behaviour does not become possibe I'll either install 0.19.8 again, or build a fork when I get the Rust stuff to compile in Android Studio. |
just want to add that my 3 years old son misses this feature so much and his father is tired of clicking in the little corner to put "PJ Masks" in full screen. |
I wonder if I'm the only one that doesn't use his.phone with auto rotate activated. i like it in forced portrait mode Right now. The full screen button 1st change the phone orientation with no way to rotate it back without close thenapp cuz the button is hidden. And if I press again goes to full screen. Super annoying. Please bring back the old behavior. |
Yes exactly, I really don't like that the video starts playing in a small viewport, I'd like it to start playing in fullscreen ALWAYS, so please include a setting to be able to use it like that, because it used to work like that before 0.20.0 and I'm rather fond of it. |
I'd like to add in support of this request that it isn't just a matter of one sole more tap:
It makes the experience really clumsy and tiring tens of times a day. Before I could reliably know that as soon as I tapped anywhere on the video thumbnail, my phone would go in landscape mode and I could start watching, no fuss. Now I am expecting the process to be clumsy and hard... I should mention that I also have my phone locked in portrait mode, as the very only time I need it in landscape if when I watch videos, which made the previous behavior so appreciated. I have tried turning autorotate on again and couldn't believed how bothering it was: as soon as I slightly moved or needed a different orientation (in bed etc.) my whole UI (outside of NewPipe) would turn and twist back and forth... I locked back in portrait and don't see myself changing. Some phones definitely have finicky gyro sensors. I am also perfectly fine with this option having to be toggled/set up on purpose in the Settings, no need to change the new defaults, but at least please offer a way to reinstate what was the default for so long. "Don't break the userspace" as they say in kernel land... Thank you for your time and efforts in developping NewPipe. |
I feel like I am stupid : |
Personally, I think if your device is locked in portrait, step 4 should cause it to rotate back to portrait. |
This comment has been minimized.
This comment has been minimized.
it would be nice if someone could recompile the GUI back from v0.19.8 in to v0.20.2 and upload the APK |
@Littlemac123, I REALLY don't think it's that simple, only in utopia are UI and the logic behind the UI so detached and compatible they are fully interchangeable. |
#4686 (comment) guys. |
@opusforlife2 I stand corrected. 😅 |
Really missing this feature. Couldn't stand this behaviour of the official client on mobile (on Tablets and desktops it makes sense) and switched to NewPipe the moment I came to know about it (apart from privacy related reasons). |
@mof22 You've already made this same comment on the correct issue (4500), so I'm deleting it here. Please don't double post on different issues out of frustration (apologies if that is not the case). Open source projects progress at the pace the developers set when they have free time. |
@opusforlife2 |
This comment has been minimized.
This comment has been minimized.
@Littlemac123 That has nothing to do with this issue. Please check other issues, or open a new one if you don't find a duplicate. |
Version
Regression
The user can no longer go into fullscreen directly upon tapping the thumbnail in the video details page, like in 0.19.8. (for those checking: requires locked system rotation and landscape mode in main player)
Additional Note
MUH FULLSCREEN!
The text was updated successfully, but these errors were encountered: