注释
是的! 正如您在 Issue #186中看到的,我使用新的 GUI 构建 UGS。我对此很满意。
|
是否有任何想法将 GRBL Comms 库的后端拆分到一个具有清晰 API 的单独 Jar 中?我正在为使用 GRBL 的激光雕刻机设备的 Visicut 编写驱动程序,并且正在考虑使用它来处理 GRBL 通信,因为所有的艰苦工作都已经完成,但不需要所有的 GUI。 |
@madeinoz67是的!你今天就可以做到这一点,看看BackendAPIReadOnly.java和BackendAPI.java。此 API(几乎)仅在MainWindow.java中使用,并且仅在UGSPlatform代码中使用。 我不太满意的唯一部分是设置的传递方式。目前有一个“设置”对象将一堆东西转储到……比如要截断多少小数或是否使用单-步模式。至少我想将预处理拆分成一个单独的 API,您可以使用它,然后使用后端 API 仅用于发送数据和获取结果。 |
我喜欢 tabless GUI 的想法,就像 Ruby 发布的那样(虽然命令行更长,在控制台窗口的顶部)。当您的鼠标使用扰流板作为垫子时,一直在没有快捷方式的情况下切换它们很烦人:P |
我想要一个选项卡最小的 GUI,它在便宜的触摸屏平板电脑上运行良好。 我所说的 tab-minimal 的意思是正常操作不应该涉及切换选项卡,但是对于不太常见的任务单独的选项卡就可以了。例如,我认为拥有一个用于管理不打算在运行机器时使用的宏的页面会很有意义。主屏幕应将宏显示为不可编辑的按钮。 当然,不同的“正常”操作可能需要一组不同的功能。这些不同的工作流程应该独立于一个选项卡中。我的意见是,GUI 上几乎所有的按钮都应该与自定义宏基本相同。只有几个特殊情况(文件打开、点动增量调整、点动单位(人们需要在正常操作中更改它吗?可以将点动单位移动到设置吗?)等)如果事情是这样设置的,主控区就是一堆宏按钮。按钮集及其布局可以作为设置而不是代码来管理。 这是我一直在添加的代码的总体主旨,只是最近没有太多时间来处理它。 |
@philreindl我早期的一个想法是集成诸如 eclipse 透视图之类的东西,以便在 UGS 平台中具有多个 GUI 配置。我可以想象的一些默认设置是“发送”、“Gcode 编辑”、“自动调平”、“经典”、“Tabless/Minimal”等。甚至可能是“平板电脑”模式,它可以启用带有大按钮的特殊插件。NetBeans 没有内置此功能,但有一个插件可以解决这个问题。 |
我开始考虑如何更好地组织 UGS 后端,以便可以扩展和/或重写前端,而不会变得更加混乱。很可能会有一堆单独的组件构成框架,而不是像今天的 MainWindow.java 这样的一个整体类。
因此,我对社区对可以创建的不同模块的愿望清单以及如何在 GUI 中组织它们感兴趣。将事物保存在模块中可以使我们也可以拥有多个前端(即共享大部分代码的独立表和模型 GUI)。
所以这是一个起点。
至于如何更改前端以包含这些东西,我不确定。像 GIMP 这样的多个窗口可以工作,但对新用户来说可能有点吓人。当前设计的选项卡很好,但有时您可能希望同时查看多个选项卡。