pressaction.lua 的替代品

[natural-harmonia-gropius]

https://github.com/Natural-Harmonia-Gropius/mpv_config/blob/main/scripts/on.lua

SPACE               cycle pause                         #@click
SPACE               no-osd set speed 4; set pause no    #@press
SPACE               ignore                              #@release

这个脚本搭配上面的 input.conf 应该能够完全代替 pressaction.lua 了。如果测试下来没有问题的话，这个脚本稳定后我将会弃用 pressaction.lua

讨论版：tomasklaen/uosc#307

[dyphire]

pressaction.lua 的功能实现感觉已经很好了（主要是使用频率非常低
不过新脚本的实现方式明显增加了扩展性，尤其是把键位绑定统一放入 input.conf 中管理的想法我很喜欢
等脚本完成后（指正式命名）我应该也会弃用 pressaction.lua

[dyphire]

有一个问题，如果其他脚本使用了mp.add_forced_key_binding绑定了同键位，是否会产生冲突？
mp.add_key_binding呢？看上面 uosc 讨论版里的描述这个似乎不成问题

[natural-harmonia-gropius]

MBTN_LEFT           show-text pressed; script-binding uosc/menu           #@press
MBTN_LEFT           show-text released                                    #@release

按压可以触发菜单，松开也会触发。菜单点击事件正常（此时被uosc接管，这个脚本失效），菜单消失，这个脚本重新生效。

在启动时调用 mp.add_forced_key_binding 的脚本就不知道了，看运气谁后执行谁生效。

[natural-harmonia-gropius]

mp.add_key_binding 在我的测试里连 input.conf 都覆盖不掉，后面再试试

[dyphire]

mp.add_key_binding 在我的测试里连 input.conf 都覆盖不掉，后面再试试

理论上不禁用--input-default-bindings 的话mp.add_key_binding会覆盖 input.conf 的同键位绑定

提到mp.add_forced_key_binding 是我感觉到它会产生冲突

[natural-harmonia-gropius]

我加了 no-input-default-bindings ，怪不得
add_forced_key_binding 确实会冲突，理论上都能靠写 script-binding xxx #@click 解决，没有 #@ 的行不受影响

[dyphire]

在测试使用中我发现了一个问题：当我将单击的键位项指定到 #! 或 #menu 后，如果不指定同键位的 #@click 则 inputevent.lua 脚本功能将失效。

这种重复键位功能绑定的处理方式可能不是很好
一种可能的解决方式：在脚本内部匹配已绑定 #@ 的同键位的 #! 和 #menu 并视作 #@click 处理

[dyphire]

不清楚是否有简洁的方案去实现这种功能提示，我担心这会让菜单列变得臃肿（更容易触发边界溢出
而且如果对 #@ 采用针对性识别处理的话我担心这种 pr 不会被合并，只能维护自己的分支（也不是不行

[natural-harmonia-gropius]

有什么软件有区分单击双击长按的提示的？
在怎么优雅的做之前，我想不出来怎么做

[dyphire]

no idea :(

[natural-harmonia-gropius]

😶‍🌫️看着好怪 natural-harmonia-gropius/input-event#17

[dyphire]

确实好怪，需要特殊化处理。但对如何良好地区分键位动作这点上毫无头绪（

[dyphire]

d1256f7 本配置正式启用 inputevent.lua 脚本并弃用 pressaction.lua 脚本

[zhongfly]

之后变成默认不启用外部配置

这并没有真正解决问题，就像我说的当启用时外部配置不存在应该尝试读取input.conf中可能存在的配置而不是静默无效，当外部配置存在保持现有逻辑

在默认不启用时，用户只可能自己在设置里显式启用，这说明他确定要使用外部配置、不使用input.conf。如果开启外部配置却还是读取input.conf是不合逻辑的。没读取到，说明他忘记或者写错路径了，那么用户需要纠正设置

[dyphire]

嗯，这也是有道理的

[dyphire]

abd5eae 切换至修改版inputevent.lua进行测试

命令执行的优先级是从上到下按顺序，执行第一满足条件的命令（是不是应该改成从下到上？）

个人觉得从下到上的优先级会更好些，一般的写法习惯是先写常规动作再写限定动作，目前的逻辑和此相反，改下会比较好
然后更新下readme后感觉可以尝试提交pr了

[zhongfly]

改完了，文档实在不想写了

[zhongfly]

把条件命令剥离出来作为单独的脚本，这样就不用修改版了 https://github.com/zhongfly/command_cond
依然是支持设置从哪读取配置文件
通过script-message-to来掉用
优先级我还是觉得改成从上到下更好，更符合直觉，即最下面的是“兜底”。我自己感觉涉及规则类的都是从上到下匹配的(广告屏蔽，代理规则等等)