-
Notifications
You must be signed in to change notification settings - Fork 818
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
[Feature Request]: Override default video player settings / Retain player settings within session #2295
Comments
Makes sense to keep everything for the session, if someone is watching a video playlist in full screen odds are they want to continue watching in fullscreen instead of having to focus freetube and manually fullscreen every video. Especially not if it is shorter videos like vines (if those still exist) or music (2-4 minute long videos generally) Considering how PiP currently works I also doubt anyone watching playlists or autoplay will benefit from having to manually close PIP every video (since it blackscreens when the video switches) and reopen a new one I don't see what usecases there would be for automatically overriding the current settings with some defaults. If anyone does have use cases that would benefit from keeping the current functionality I'd be happy to hear about them, but as things currently stand I don't see a reason to make this a toggle instead of just replacing it with the current volume functionality |
I'm working on a feature adding stylized radio button groups an
To start off, we can probably only display levels 3, 4, and 6 of the settings manifesto, as those are the easiest. 3 is just saving in component state, 4 is using |
Simpler idea: what about a toggle or checkmark on the Watch route titled something like |
The default settings or if it changed? |
Settings scope 4 on the manifesto is what I had in mind:
|
4 seems like the most logical route to me. |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
I think four options would be best:
In addition there could also be: |
This comment was marked as duplicate.
This comment was marked as duplicate.
4.a. makes perfect sense. |
As a user, I support the implementation of full-screen mode, particularly in the context of the ongoing discussion about improving video player settings. However, there is a current issue where, in Auto Play mode, the full-screen mode is automatically exited when the next video starts. Unfortunately, this exit from full-screen mode is not detected or addressed. |
Guidelines
Problem Description
When #2263 was opened up. I noticed how many issues were actually opened for the same request. So here we are making a big summary.
Why do we want this? Let say in the settings i have set my default video quality to 1080p. My internet provider is giving me a hard time today so while im watching a video i switch from 1080p to 360p in the video player. The next video should also run in 360p because i just have overwriting the default quality because my provider giving me a hard time.
I could write usecases for the rest but i assume u get my point. U change it in the player for a reason.
Proposed Solution
Player buttons from the left to right, that already do this.
*There is a setting called
Enable Theatre Mode by Default
. When this is enabled Theatre mode will always get forced on u on the next video. If this is disabled and u switch from default view to theatre mode view in the video player. It will retain these setting.Alternatives Considered
I do understand that some people like it that the default settings overwrite the player settings when a next video is being played. We maybe could have 2 modes?
Issue Labels
ease of use improvement
Additional Information
I understand that this will be a difficult and long discussion. The point of this issue is to centralize the discussion to this issue instead of 8 other issues.
Allot of discussion has already taken place here.
Most important bit of discussion is the settings scope manifesto provided by @jasonhenriquez
The text was updated successfully, but these errors were encountered: