* feat: apply margin to `osd-margin-y` and `osd-margin-x`
The margins were already set for `osc-margins` and
`user-data/osc/margins`, but osd messages have their own properties
`osd-margin-x` and `osd-margin-y`.
Offsetting `osd-margin-x` and `osd-margin-y` by our margin prevents
overlap of osd messages with the GUI.
Added option `top_bar_alt_title`, which accepts an alternative title template to be displayed, and `top_bar_alt_title_place` that controls where it should be displayed. It can be either `below` to place it below the main one, or `toggle` to show it in place of the main title when user clicks the top bar or calls the `toggle-title` binding.
The `top_bar_title` now also accepts a custom top bar title template if user wants it to be different from the one defined in `mpv.conf`.
closes#402
`destination_time` accepts one of `total`, `playtime-remaining` (scaled by the current speed), `time-remaining` (remaining length of file).
`total_time` is deprecated, but still works as expected.
The `shuffle` option built into mpv doesn't shuffle playlist playback, but instead just randomizes the order of every new opened playlist. So when you enable this after opening a playlist, it does nothing. If you enable it before opening a playlist, it'll randomize its list order, so you can't browse alphabetically. None wants this, none expects this. And since its is expected from a ui such as uosc to provide a shuffle button that works like in any other media player on the planet, I had to simulate it.
It decides on the next file 300ms before the end, so it can potentially cut out punchlines from short videos such as those from r/perfectlycutscreams. But this is necessary because a lot of files actually end like ~100ms or more before their duration, but on corrupted files or files where stream ended prematurely, this can happen way before that. If file is force ended by mpv before our timer kicks in, our simulated `file-end` event won't fire, and uosc is unable to take over to decide to play the next one.
I couldn't figure out a better way to implement this. There's no 'fil-reached-end' even in mpv. There are only 'im-unloading-the-file' events (`file-end`, `on_unload`, ... etc), which is useless here because it triggers even when user opens a different file during playback.
Implementing `shuffle` allowed for trivial `next_file_on_end`, so that got added as well. It load next file in directory when current file ends.
Directory navigation now also adheres to `shuffle` uosc option, and `playlist-loop`, `playlist-repeat`, & `loop-file` mpv options.
Additionally, the `<has_playlist>` disposition was removed from the `shuffle` and `loop-playlist` control bar buttons as they now affect directory navigation as well.
closes#235
Users can no longer create their own or edit existing chapter range serializers, but that was always very limited and prone to errors. Instead, all common use cases for chapter ranges: intros/openings, outros/endings, and sponsor blocks serializers are now internal.
Users can still disable and configure colors for each individual serializer by specifying a `{type}:{color}` pairs delimited by a comma on a `chapter_ranges` property. The color is now an RGB(A) HEX code.
Adds `has_many_audio`, `has_many_sub`, and `has_many_video` disposition types that can
be used when constructing the controls bar.
The audio track selector button now has a `<has_many_audio>` disposition instead of the old `<has_audio,!audio>`.
It is now possible to specify a threshold when to hide the badge by doing `#audio>1` to display the audio counter badge only when there's more than 1 audio track.
ref #212
Also removes the counter from built-in playlist related control buttons, as big playlists create badges that are too big and overlap/overflow the button too much. And having the counter there will make people ask for position (understandable), which would further worsen this problem. Better to have it in the top bar.
ref #212
