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
All of the old styles had visibility issues, and rendering code was a bit too overcomplicated. This fixes all if it by rendering chapters as diamond indicators on top of the timeline.
`timeline_chapters` option is now a boolean, and `timeline_chapters_opacity` & `timeline_chapters_width` have been removed.
This means chapter rendering is no longer configurable, as they resize based on timeline size, and inherit its opacity and border size, so I don't see what anyone would want to configure here, but I'm sure I'll get some requests as always :'(.
ref #206
With this, the codebase is mostly typed (as much as sumneko's type checking allows), and finally go-to-definition-able.
This refactor changed or touched more than 90% of the codebase, so here's just the most notable changes I can recall:
Menu implementation is now way more robust, and supports:
- live menu updates
- opening submenus allows navigating to parent menus
- items icons and bold & italic styling
- keeping menu open after selecting the item
- peeking submenus
- and a lot of other small tweaks
The menu input data structure changed. It no longer accepts `active_index` and `selected_index`, instead, each item can now have `active` or `selected` property.
And I'm sure there's a lot I'm forgetting to mention, but it's midnight here T.T
closes#144, ref #171, closes#176
