Skip to content
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

Implement OSC toggle as an alternative to cycle #15656

Open
ericpruitt opened this issue Jan 6, 2025 · 0 comments
Open

Implement OSC toggle as an alternative to cycle #15656

ericpruitt opened this issue Jan 6, 2025 · 0 comments

Comments

@ericpruitt
Copy link

ericpruitt commented Jan 6, 2025

Expected behavior of the wanted feature

The OSC message "osc-visibility" allows the user to cycle between "never", "always" and "auto." I don't find this behavior ideal because I always want to toggle between on/off which means always/never or always/auto, and that's how the other media players I've used work. I wrote the following script that I use in my mpv configuration:

-- Toggles the on screen controller between being always on and either
-- automatic mode or completely hidden depending on what the initial visibility
-- value was. If this is used in conjunction with "osc-visibility cycle", the
-- uncorrelated state used by the two messages may result in neither behaving
-- as expected.
mp.register_script_message("osc-toggle",
    (function ()
        local cursor
        local states

        local osc_conf = {
            visibility = "auto"
        }

        (require "mp.options").read_options(osc_conf, "osc")

        if osc_conf.visibility == "auto" then
            states = {"always", "auto"}
        else
            states = {"always", "never"}
        end

        cursor = states[2] == osc_conf.visibility and 2 or 1

        return function ()
            cursor = cursor == 1 and 2 or 1
            mp.commandv(
                "script-message", "osc-visibility", states[cursor], "no-osd"
            )
        end
    end)()
)

I'm willing to update osc.lua to integrate this logic into the upstream codebase, but I wanted to see if the PR would be welcomed before potentially wasting time on it.

Alternative behavior of the wanted feature

No response

Log File

No response

Sample Files

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant