MBTN_LEFT dragging window conflicts with mpv-player/mpv#14251

[verygoodlee]

MBTN_LEFT dragging window conflicts with mpv-player/mpv#14251

[verygoodlee]

看起来还是官方的补丁有问题，不仅与inputevent冲突，还把所有OSC脚本的进度条拖动功能给破坏了

[verygoodlee]

OSC进度条拖动已经修复了 mpv-player/mpv@0509e5b ，但还是与inputevent冲突

[natural-harmonia-gropius]

mp.add_forced_key_binding(
    "MBTN_LEFT",
    "MBTN_LEFT",
    function(e)
        print(e.event)
    end,
    { complex = true }
)

拖动时立刻打印 down, up , mpv那边改成 down，drag 或者其他方式通知 drag 事件才能修。

今天 shinchiro 的自动编译没出来，过两天再看看

---

我现在 uosc 的进度条不能拖

[verygoodlee]

zhongfly的构建比较快 2024-06-06 12:10，进度条拖动应该没问题了。

与脚本按键绑定冲突的原因 mpv-player/mpv#14251 (comment) ，
已经修复还没合并，加了一个取消标记，可以先下载这个自动构建 mpv-player/mpv#14311 (comment) 。

我试了一下，这样改可以

function InputEvent:bind()
    self.exec_debounced = debounce(function() self:exec() end, self.duration)
    mp.add_forced_key_binding(self.key, self.key, function(e)
        if e.canceled and self.key:upper() == "MBTN_LEFT" then
            self.queue = {}
            return
        end
        self:handler(e.event)
    end, { complex = true })
end

本来想只用if e.canceled一个条件的，测试发现可能会丢失release操作，
比如当按住a保持不动，再去按其他键，此时a会被打断，触发一次up事件并且canceled=true，如果直接抛弃的话会把release操作吞掉。
只抛弃左键的取消，影响应该是最小的，就是太硬编码了，
你有其他更优雅的方式也可以试试，根据我的测试canceled=true好像只与up事件一起出现，一个键被其他操作打断时触发。

[natural-harmonia-gropius]

#50

盲改的，我有空试一试 @drag 正不正常

[verygoodlee]

我觉得@drag没啥太大意义，而且仅凭鼠标取消信号就判断为拖动是不准确的

• 在菜单打开状态下，使用左键关闭菜单，也会触发
• 按住鼠标保持不动，再按其他键打断鼠标，也会触发

[verygoodlee]

补丁已经合并了，最新的zhongfly和shinchiro构建都能直接用了。

想到个不错的方案，碰到取消信号时忽略@click，类似获取焦点时那样，
最大的优点：在菜单打开状态下，使用双击依旧可以切换全屏，因为第一次的取消信号只忽略@click，不影响第二次触发@double_click
小缺点：如果拖动时间极短，然后紧接着一个单击，也会触发全屏，不算什么很影响使用的问题，基本可忽略

function(e)
    if e.canceled then self:ignore('click', self.duration) end
    self:handler(e.event)
end

[natural-harmonia-gropius]

#50

改了下，我试了下感觉没什么问题

[natural-harmonia-gropius]

fixed b9fb2bd