上周在曼彻斯特举行的 GUADEC 大会上,GTK+ 的维护者和感兴趣的人们在非正式会议日举行了工作会议。
Georges 已经在他的博客文章中很好地总结了结果,你应该阅读一下(即使只是看看聚在一起的 GTK+ 人员的照片)。
GTK+ 3
我们简要讨论了 GTK+ 3。我们的印象是,大多数人都很享受 GTK+ 3.22 带来的稳定性,并且不急于尝试新的、稳定性较差的工具包版本。
普遍的共识是,我们应该对 GTK+ 3 中的 API 添加保持相当严格的立场,但当有足够高的好处时,允许添加新功能。这方面出现的例子是 Wayland 的客户端与服务器端协商协议支持,或者彩色表情符号支持。
GTK+ 4
大部分时间都用于讨论我们希望或需要为 GTK+ 4 完成的所有事情。我们对谁将负责完成这些项目都有一个很好的想法,但我们没有确定完成它们的非常详细的时间表。
最后,我们收集了一个我们认为是阻碍因素的项目列表
- 基于约束的布局
- 支持在 ui 文件中定义状态和转换
- 设计器支持
- 将键盘处理转换为事件控制器
- 非回退文本渲染
- 一个完成的 GL 渲染器
- GDK 中对子表面的干净支持
- GDK 中不再有根窗口
- 事件清理
这些要点中的一些值得更详细的讨论。
基于约束的布局、状态和设计器支持
使用约束的布局是一个灵活的系统,它在其他平台上已经取得了成功。更重要的是,它更接近大多数人思考在屏幕或纸上放置事物的方式,并且它有望提供一种通用的语言,让 GTK+ 应用程序的设计者和开发者可以进行沟通。
Emmanuele 和其他人一直在开发的 Emeus 小部件使用约束来查找单个容器的子小部件的位置和大小。
将其集成到 GTK+ 中的计划更具雄心:我们设想每个顶层窗口都有一个约束求解器,窗口内的所有容器都将它们的约束添加到其中。这将需要 GTK+ 中的当前容器以约束的形式表达它们的布局算法,这在大多数情况下应该不会太难,并且可以逐步完成。
状态及其之间的转换是 Christian Hergert 在 libdazzle 中原型化的东西。这里的想法是在 ui 文件中定义一个复杂的小部件(例如对话框),以及它的主要状态以及它们之间的转换应该如何工作。这将使我们拥有一个不仅仅是在画布上排列小部件的 UI 设计器工具,而是走向故事板和设计转换。当然,这说起来比做起来容易得多…
键盘处理
Christian 花了一些时间来描述他为 gnome builder 编写的快捷键引擎,该引擎目前位于 libdazzle 中。它有一些有趣的功能,例如捕获-冒泡事件处理、和弦(例如 Ctrl-C Ctrl-X 等多键序列)、与操作的紧密集成以及自动生成键盘快捷键帮助的能力。
该领域的计划是从 Christian 的引擎中提取最佳功能,并将其转换为一个或多个 GtkEventControllers。一旦这项工作完成,我们将转换所有小部件以使用事件控制器而不是按键信号处理程序。
GtkBindingSet 也将被事件控制器取代。
文本渲染
GSK 的 Vulkan 渲染器或多或少已经完成。它可以有效地使用着色器渲染 CSS 机制生成的大部分内容。最大的例外是文本:目前文本的处理方式是,我们使用 cairo 将其渲染到表面,然后将表面上传到纹理,然后在渲染节点中使用它。对于每一帧。
这里需要做的是,我们将需要的字形上传到我们保留为图集的大型纹理中,然后创建引用该图集的文本渲染节点。
由于文本是用户界面中非常重要的组成部分,因此在我们为 Vulkan 实现正确的文本渲染之前,我们不能真正声称我们已经验证了渲染节点方法。
GL 渲染器
Benjamin 完成了将 Vulkan 渲染器提升到几乎完成状态的大部分工作。当他这样做时,GL 渲染器已经落后了 - 它没有 Vulkan 中使用的着色器。
这里需要做的是抽象出共同的部分,并将其余部分从 Vulkan 反向移植到其 GL 等效项。这方面一个不太有趣的地方是,我们最终可能需要不止一个 GL 渲染器变体,用于旧的 GL 和 GLES 平台。但我们可能至少在最初可以只使用一个现代 GL 渲染器。
字体和文本
一个单独的会议专门讨论了文本渲染堆栈中的新功能。这里的主题是可变字体和彩色表情符号。不幸的是,我错过了大部分讨论,但结果的总结是
- Behdad 对 pango 和 fontconfig 中支持可变字体需要做什么有一个粗略的计划。这涉及到 PangoFontDescription 中用于指定轴值的新语法以及 PangoFontFamily 中用于获取有关可用轴的信息的新 API。
- 在 GUADEC 期间,Behdad 合并了 cairo、fontconfig 和 pango 中对彩色表情符号的支持,我开始在 GTK+ 中实现一些简单的表情符号输入。现在,GTK+ 3 和主分支中也都已完成。
其他
我们还触及了许多其他主题,这里无法一一总结。其中之一是辅助功能的状况,但那是另一个时间的话题。
伙计们,关于你们的布局,至少快速浏览一下 Java 中的 MigLayout
http://www.miglayout.com/QuickStart.pdf
在我做 UI 的这些年里,我从未见过像这样简单而强大的布局系统。我们用它做了一些疯狂的 GUI,具有比例调整大小、20-30 个控件等。这是我见过的任何语言、任何平台上最好的布局管理 API。
Jacek,你应该在 https://ebassi.github.io/emeus/ 上阅读一些关于 Emeus 的信息
>我们设想每个顶层窗口都有一个约束求解器,窗口内的所有容器都将它们的 >约束添加到其中
这会不会限制人们在子小部件的子集上尝试其他约束和布局算法的能力?
>这里需要做的是,我们将需要的字形上传到我们保留为图集的大型纹理中,然后创建 >引用该图集的文本渲染节点。
请注意,当执行此操作时,为了使抗锯齿正常工作,您不仅需要每个正确大小的字形,还需要每个(字形、前景色、背景色)的组合,尽管一些巧妙的掩蔽可能会减少空间需求。
此外,这里有一个非常好的快速字体渲染器:https://github.com/google/font-rs
为什么不完全使用 GPU 渲染字体?您目前的方法意味着您只是缓存软件渲染的字形,并且您需要为每个字体大小执行一次。为什么不将字体的几何形状存储为纹理,并让着色器完成这项工作:http://wdobbie.com/post/gpu-text-rendering-with-vector-textures/
您绝对应该公开底层图形系统的特性。因为我在 Apple OS X 上遇到了各种问题。
因为我必须将我的应用程序计算能力与 Gtk+ UI 线程同步。这在使用 Xorg 的 GNU+Linux 上不会导致任何问题。但我认为在 Aqua 上运行后,我所有的同步工作似乎都没有价值。
目前我使用 Gtk+-2.0,即使使用 gtk_main() 和 g_source_attach(),似乎也可能出现竞争条件。