开源改变世界!!

热键 – 经典 vs 平台 #397

推推 grbl 1年前 (2023-01-26) 101次浏览
关闭
philreindl 打开了这个问题 2016 年 4 月 26 日 · 1条评论
关闭

热键 – 经典 vs 平台#397

philreindl 打开了这个问题 2016 年 4 月 26 日 · 1条评论

注释

热键 - 经典 vs 平台 #397
贡献者

@winder
热键管理是我接下来要解决的问题之一。100% 的人同意两个构建之间的热键应该共存并且最好共享映射。

在高层次上,我认为 GUI 后端应该负责键盘事件。首要任务是处理这样一个事实,即如果按下箭头键,命令窗口和文件浏览器将不会阻止点动。我考虑的处理方式是让后端公开一个新的“grabKeyboardFocus”方法,该方法将在获得焦点时由使用键盘的 UI 控件触发。因此,浏览窗口、命令文本字段、宏编辑字段等在获得焦点时都会触发该方法。当失去焦点时,还需要一个“releaseKeyboardFocus”方法。

另一个主要变化是每个按钮/小部件都将自己注册到后端 api。他们会给出一个标识字符串(可能可以使用本地 id)和一个回调函数。然后我们将定义一个键盘映射以将键盘按钮绑定到 id 字符串,然后在按下键盘按钮时触发适当的回调。

这或多或少符合您对平台 UI 的想法吗?

热键 - 经典 vs 平台 #397
所有者

通过让热键共存,我真的认为我们需要确保 swing GUI 中的热键不会泄漏到平台中,反之亦然。我认为热键应该单独处理。BackendAPI 的想法是,GUI 想要做的事情被暴露出来,由任何存在的表示层设施控制,这些设施将用于控制界面。

您描述的方法仍然有意义,但它将在一个连接到主窗口键盘侦听器的类中。由于 Netbeans 平台提供了自己的快捷方式管理器,因此很难共享设置。

以编程方式轻松调用后端也是我遇到的一个问题。理想情况下,您需要一个像您描述的那样的热键/ID,而我制作原始界面的方式并不存在。(设置对象也是如此)。我试着让这项工作变得更好一点public void performAction(ACTIONS action)

为了处理键盘焦点,我选择让热键更加深思熟虑。因此,它不会使用“箭头”,而是默认使用“命令箭头”之类的东西。