Controls bar

[tomasklaen]

I'm in the middle of implementing controls bar, and wanted to check if anyone has any inputs about things I'm doing wrong, sub-optimally, or missing.

It'll be a transparent bar above timeline that can be laid out and filled with various user defined controls.

Here's the current spec/config documentation on how it'll work:

# A comma delimited list of elements to construct the controls bar above the timeline. Set to `never` to disable.
# Parameter spec: enclosed in `<>` means required, `[]` optional
# `<icon>` - common parameter used to specify an icon name (example: `face`)
#   - search for and pick one here: https://fonts.google.com/icons?selected=Material+Icons
# Available elements and their parameters:
# `<usoc_command>` - preconfigured shorthands for uosc commands that make sense to have as buttons:
#    - `menu`, `subtitles`, `audio`, `video`, `playlist`, `chapters`, `stream-quality`,
#      `open-file`, `next`, `prev`, `first`, `last`, `audio-device`
# `playlist-or-open-file` - opens playlist if any, or open file menu otherwise
# `fullscreen` - toggle fullscreen
# `speed:[scale]` - display speed slider, [scale] - factor of controls_size, default: 1.5
# `command:<icon>:<command>` - button that executes a <command> when pressed
# `toggle:<icon>:<prop>` - button that toggles mpv property
# `cycle:<default_icon>[!]:<prop>:<value1>=[icon1][!]/<valueN>=[iconN][!]`
#   - button that cycles mpv property between values, each optionally having different icon and inverted flag
#   - presence of `!` makes the icon look inverted (disabled)
#   - default icon is inherited when not overwritten, but inverted flag is not
# `gap:[scale]` - display an empty gap, [scale] - factor of controls_size, default: 0.5
# `space` - fills all available space between previous and next item
# Example implementations of some of the shorthands:
#   - menu: `command:menu:script-binding uosc/menu`
#   - fullscreen: `cycle:fullscreen:fullscreen:true=fullscreen_exit/false`
#   - `toggle:<icon>:<prop>`: `cycle:<icon>:<prop>:true/false!`
controls=menu,gap,subtitles,audio,space,speed,space,prev,playlist-or-open-file,next,gap,fullscreen
controls_size=36
controls_size_fullscreen=48
controls_spacing=4

[junguler]

this sounds amazing, i really appreciate the recent resurgence of activity in this repo, the only thing i want is to have separate button layouts for videos and audios if possible, all i want when listening to audio is prev and next buttons but when watching videos i like to have many options

[christoph-heinrich]

I already thought about implementing this (inspired by the menu button), but since I didn't actually need it myself I didn't bother.

With space the rest gets effectively aligned to the right side? What happens if I have multiple spaces? based on the example I would guess that with 2 spaces the one in the middle gets centered, but what if I add another space somewhere in there?

My ideas regarding layout were to have horizontal and vertical layout with both left and right alignment, so that user can e.g. make an L shape with their buttons in the left bottom corner if they want to.
I also thought about a triangular layout where the corner gets filled up with buttons.
Not sure if any of that would actually be useful, they are just the ideas I had when I first thought about making that.

Looks pretty good overall 👍

[tomasklaen]

After elements claimed their required area, spaces divide the rest evenly amongst themselves. So yes, doing space,foo,space will center the foo, and you can use gap:1 to center stuff perfectly if one side has less elements than the other.

I thought about an additional controls_vertical menu that would display itself on the opposite side to the volume, but not now. Maybe in the future when I have nothing else to do.

And I don't see much value in implementing multiple layouts based on file type. Controls that are not available for current file type turn themselves into gap:1, which results in nicely consistent element placement. Having multiple layouts feels like bloat both in code and config imo.

[christoph-heinrich]

spaces divide the rest evenly amongst themselves

Ok then please mention the behavior of multiple spaces in the description. Users would certainly figure it out through trial and error, but providing that information upfront doesn't hurt.

[tomasklaen]

All right so this is now on main. There were a couple changes in config spec form the example above, so read the uosc.conf if you want to try it out and tweak for yourself.

[christoph-heinrich]

I haven't done a whole lot of testing yet, but I'm not too fond of the changes to the speed widget.

Drawing that background so far into the video seems distracting, but maybe I only perceive it like that because I'm so used seeing it without background, and from a readability perspective it certainly makes sense.

Because it is so different to the other controls, I think it should continue to honor the speed_size and speed_size_fullscreen settings. I haven't looked at the commit yet, but the size calculation seems to have changed. controls_size=36 is the same size as speed_size=46 used to be.

The speed option can be removed now.

[tomasklaen]

😳 I forgot to clean up obsolete options. Done now. Speed placement, size, and visibility is now dependent on controls configuration, but it does retain its own persistency.

You can control the scale of the speed relative to the rest of the controls with speed:1.5 where 1.5 is a factor of current controls size. Default is 1.3.

And yes, speed is now way more readable and usable with the background, especially since there can be other elements around it. Since it's interactive, it is now obvious where you can click to reset, or scroll/grab to change. Before it was kid of a guess work, so UX is definitely better. I liked the simplicity and cleanliness of the transparent one too, but can't argue that this is just better to use now.

[tomasklaen]

Also added tooltips, as icons are not descriptive enough sometimes.