Closed barisgul15 closed 6 months ago
Your Testserver will be ready at https://1234.test.live.mm.rbg.tum.de in a few minutes.
I am not really involved in the project and more like a user but I do have two suggestions:
add more options. Doesn't really have a downside, does it? (especially combined with the other suggestion)
PRs are welcome!
I am not really involved in the project and more like a user but I do have two suggestions:
- change "seconds" to "s" or move the unit straight to the title. To me the current way feels cluttered
- add more options. Doesn't really have a downside, does it? (especially combined with the other suggestion)
For the first point, i will look into it. Aesthetics is definitely not my strong point and i am open to every suggestion. For the second point, it is really easy to add more options, because seeking time is already added as user setting and it will be given the value user choses, so what just adding new options on html code will be enough. But do someone needs more than these? I assume that by more options you meant more than 15 seconds, but does someone ever needs to seek a video more than 15 seconds?
Motivation and Context
Issue: https://github.com/TUM-Dev/gocast/issues/1171 The seeking time of a video was set to 15 second and it can not be changed. Sometimes to hear what just said 15 seconds can be too much.
Description
There used to be no user setting option related with seeking. Now the seekingTime is also added to the user settings. A button to choose the seeking time is added to the settings page of user. It is still set to 15 seconds as default, but now the user has also the options of 5 or 10 seconds a seeking Time. When the popular video platform on the web are examined, the general seeking options were 5, 10 and 15 seconds. Therefore there is no more option is added, but can always be added just by expanding the button because backend is already set. The option of whether allowing user to write his/her own seeking time can be discussed, but thought that these three options are enough to solve the issue and also giving concrete options in a rather small matter seemed more appropriate.
The created button changes the new user setting SeekingTime. For seeking then the new value is used. Since user settings can store a value as a String, the conversion from String to a number/int was done in the backend, not in the frontend of the code. It is chosen so, because the same method is also used for playbackspeeds and making this conversion on the backend seemed more robust.
For getSeekTime and updateSeekTime methods, the already implemented get and update methods of the other user settings are considered and these methods were created accordingly.
Steps for Testing
Prerequisites: Having a tumlive account
Screenshots