增加对鼠标按键的支持

[LuSrackhall]

[LuSrackhall]

是将 原有键盘的专辑功能 和 将要实现的鼠标的专辑功能 给独立开, 还是说做到一起(即现在已有的键音专辑的功能内部)。从产品角度来看, 各自都有利有弊, 实在不好权衡。

因此我正在思考是否能够将其做的 —— 即结合, 又各自独立。
虽然这个思考角度最终实现后, 可能和KeyTone中的键音继承功能一样是个伪需求…但我确实希望这个产品是这个样子的。

至于 框选音效 之类的功能, 因偏离本项目的产品定位, 可能暂时无法实现。(即使未来实现, 也需要等到产品定位中的主要功能的完善及稳定后了)

[LuSrackhall]

可能大家不理解我表述的 即结合,有各自独立的 含义

我来解释下,

• 所谓结合 , 就是说, 把鼠标音效的设置, 做到当前的键音专辑功能之中, 可以和当前的键音专辑一起进行设置。

  也就是说, 一个键音专辑中, 可以即包含键盘声音, 又包含鼠标声音。 也可以只包含键盘声音, 或 只包含鼠标声音。

• 所谓又各自独立, 就是说, 用户可以在使用时, 可以选择鼠标专用键音包。(如果选择了鼠标专用键音包, 则当前所选键音包的鼠标键音将被选择的鼠标专用键音专辑的鼠标键音覆盖)

  这样一来, 用户在不喜欢某个键音包中的鼠标键音(但喜欢键盘键音)时, 可以独立挑选喜欢的鼠标键音专辑来使用。

  也就是说, 最后用户可以选择两个键音包, 指定哪个作为鼠标键音播放, 哪个作为键盘键音播放。

当然, 以上的做法可能会增加实现的复杂度(我不在乎), 但在用户体验方面, 不管是键音专辑的作者, 还是使用键音专辑的用户来说, 都是双赢的。

产品理应以用户为中心, 这是初衷, 功能的实用性和软件的稳定性永远是第一优先级

[LuSrackhall]

实现此需求, 需要对代码进行大范围的重构(并伴随大量的重构后的测试工作)。

好在项目前期的设计和代码结构比较优秀, 重构工作量勉强可以接受。

自己已经开始期待鼠标支持的效果了。

[LuSrackhall]

• 单键录制时, 鼠标左键无法通过chip项的删除按钮, 删掉录制上的鼠标左键。 #78 (此为影响用户体验的bug, 需要修复)

  感觉可以通过获取组件子元素后, 在子元素项上绑定相关鼠标事件, 以阻止鼠标默认行为来解决。
  上面的感觉是错误的, 根本原因是 录制按键 的行为仅依赖由sdk通知的按键事件, 阻止浏览器前端api的任何事件是无法解决问题的。

  解决方案: 向下面的修复一样, 可以通过一个标志位来避免删除时触发记录的动作。可通过select组件中提供的@remove事件来确认标志位, 以告知自动记录逻辑目前正在触发删除操作, 使其跳过本次记录工作。

• 支持鼠标单键录制后, 若开启自动录制功能(即点亮自动录制按钮), 在开启行为本身会自动录制上鼠标左键。 #77 (若用户不想选择它, 则只能够通过关闭录制功能(即使自动录制按钮变暗)后, 再进行删除。 这似乎也可能会影响用户体验。)

  补充: 此bug还会引起鼠标左键的keycode记录到键音包配置文件中的temp名称出现不符的bug。(必现: 反复点击 激活/失能 自动录制按键的图标, 并在此期间记录其它按键, 就会观察到相关bug。) -> 删除原因: 记录到键音包配置文件中的temp名称出现不符的bug, 与当前bug无关。(且按理说, 这个就不算一个新bug——毕竟temp名称的功能是以前开发过程中被我抛弃的设计——当时忘记删除了而已)

  当前bug的原因是 录制按键 的行为仅依赖由sdk通知的按键事件, 虽然依赖前端的图标按键是在 抬起后标志位才置true, 但仍不影响sdk通知相关监听中某个dikCode有down至up是被触发。

  解决方案: 感觉可以通过一个计数器来解决, 每次切为True时对计数器作清零操作即可。(补充, 由于仅计数到1即可满足需求, 因此使用bool标志位来代替计数变量的解决方案可更加节省空间)

以上两项虽影响体验, 但不至于影响正常使用, 因此排期上可以先放放。

• 发现个问题, 似乎在录制过程中会优先使用temp式的名称---我印象中之前开发的时候不是这样写的逻辑呀, 可能是重构过程中诱发的新问题吧! #75 -- 有待进一步测试。(而且配置文件中, 也有关于temp式名称的记录, 即使这些键已经被内置。 ----但最最关键的是, 这些记录吧keycode码给搞错了, 似乎有些时候, 它记录的名称与keycode码不一致, 或者说其名称无法匹配到sdk的正确keycode码。

  关于优先使用temp式名称的问题, 已查明是因为sdk代码中重构类型逻辑链条导致的。(由于sdk向前端的传输的值的类型, 由数值类型变成了字符串类型而引起的, 因此需要通过 将sdk向前端的传递的值的类型重新改回值类型<已采纳> 或 重构前端相关的类型逻辑链条为字符串<未采纳>。)

  关于temp式名称在配置文件中的记录, 属于默认行为, 不属于bug。(这个是我当时为了实现, 按键在桌面上的展示功能时设计的钩子, 后续又因为设计缺陷被我给抛弃了但相关的代码并没有删除)
  删除已被抛弃的设计的相关代码——关于temp式名称在配置文件中的记录的相关功能代码 以及 label展示相关功能的代码。 #76

  关于temp式名称在配置文件中的记录吧keycode码给搞错的原因, 主要是因为 开启/关闭 按键录制按钮 在开启时 触发鼠标左键的自动记录的bug导致的。(除鼠标左键外, 暂未发现其它键的keycode码被错误记录 其它键也存在类似问题。) 原有的temp式名称自动记录配置文件的逻辑的问题, 当时实现的就存在bug。(没管的原因可见当时提交中相关功能的注释 —— 大致意思是temp时的名称记录以及展示介于 准确名称和dik码之间非常尴尬, 以至于可有可无, 因此当时对它的定位就是脱离生产以后可能删除的一个定位, 其不管是在功能还是ui展示中, 均未起任何作用。 因此, 其当时是否存在bug是无足轻重的。)
  也就是说, 其当前是否存在bug, 也是无足轻重的。甚至是, 我认为需要将相关逻辑彻底从代码中删除的工作可以加入排期了(当然, 如果有空了加, 没空了就再拖一拖)。

以上一项虽有实质性bug, 但多为ui和显示层面的, 不影响真正的键音核心逻辑, 因此排期上可以先放放。

• sdk 核心在调试过程中偶尔发生 panic的崩溃情况, 需进一步测试来定位原因, 以便后续修复。(若测试发现仅为调试过程中可能发生, 不影响生产的化, 则可以选择性修复。

  目前猜测原因仍与并发有关, 似乎是 在viper置为nil的空档, 被某些grouting读取而造成的。虽然很难复现, 但我确实见过几次--可能是开发过程中的某些错误传值造成的而生产中根本不存在。 总之, 需要进一步测试问题出现原因以及审视并发临界区的设置是否有遗漏。 原因已查明, 并非sdk的bug, 只要没有选择键音包, 就会正常抛出这个错误——仅作为未选键音包时提示开发者的作用, 并非异常。

以上一项为最新发现的 核心sdk 奔溃bug。若后续测试定位其影响生产, 则排期为第一优先级。

增加鼠标支持的核心功能

以下为鼠标支持设计的主要功能项, 排期优先级最高。(可能会不断添加, 修改, 会不断的在开发过程中完善需求)

• 为 mouse事件 button(keycode)相关的唯一标识符, 从前端定义默认名称。
• 为 mouse支持后的 鼠标按键音, 单独设置符合实际鼠标声音的嵌入测试音, 而不是复用现有的键盘测试音。 #81
• 为用户提供是否开启 键盘/鼠标 键音的新功能(键音专辑内)(可自行选择设置 启/禁用 键盘按键音 或 鼠标按键音)。

  没必要, 因为现有的键音专辑功能, 已经可以满足禁用鼠标按键音的功能了, 没必要在键音专辑功能内部画蛇添足。

• 为用户提供是否开启 键盘/鼠标 键音的新功能(主页全局界面)(可自行选择设置 启/禁用 键盘按键音 或 鼠标按键音)。
• 支持选择多个键音包, 以满足 用户 使用 分散在不同键音专辑中的 所喜爱的 键盘 和 鼠标键音。(可能是伪需求) 对主界面的键音专辑选择和使用, 重新设计独立的中间层抽象, 使得选择可以更加灵活, 还能减少非专辑编辑场景下的日常内存占用。 #122
• ......

[LuSrackhall]

周末结束, 又要上班了, 下班有空了做(机率小), 或等新的 周末做了(这个我可以保证)。

需要这个功能的用户, 可能需要再耐心等一段时间了~~