和往年一样,我们在塞萨洛尼基的 Guadec 举办了 GTK BoF。今年,我们有相当多的人参加了——每个人都对 GTK4 的计划很感兴趣。
但是由于 Emmanuele 上午很忙,我们先从其他主题开始讨论。
GLib
我们从会议室收集了一些关于 GLib 有用补充的建议。
- 用于获取操作系统信息的 API(基本上是 /etc/os-release 中的数据)。这似乎没有争议;Robert 将会实现它
- 一个有序的映射。这在许多地方都是通过将哈希表与列表或数组组合而临时实现的。大家似乎都同意,如果有人努力提出 API,在 GLib 中提供这个是有价值的
关于有序映射的讨论也涉及到了通用容器接口;Philipp 描述了如何做到这一点,详情请见此处。
还在容器的主题上,Alex 描述了关于传输注释的问题。我们讨论了各种想法,但可能没有完美的解决方案。
Matthias 指出,Pango 中仍然有一些 Unicode 数据。我们简要讨论了如果有一个商定的、可内存映射的 Unicode 数据二进制格式,以便每个人都可以共享它,那将是多么的好。如果没有,将最后一点数据移到 GLib 中是没有争议的。
深色模式
自从“深色模式”BoF 加入我们后,我们转而讨论深色模式。第二天在厂商主题BoF 上对此主题进行了更多讨论;GTK 的讨论侧重于如何实现深色模式的技术细节。
有多种选择
- 在主题索引文件中添加额外的元数据,以将主题标记为深色
- 添加一个“dark-theme-name”设置,并将深色和浅色主题视为独立的
- 保留现有约定,在主题名称后附加“-dark”来查找主题的深色变体
保留现有约定的务实解决方案似乎得到了会议室的支持。Matthias 开始探索一些应用程序支持 API 此处。
GTK
最终,我们转而讨论 GTK4 的状态和进展。高层次的总结是,GTK4 仍然需要完成一些特性
- 一个可扩展的列表视图,可以回收行部件。这包括在更多地方更广泛地切换到使用列表模型。为了使其完整,它还应包括使用该技术的网格视图。Benjamin 正在做这项工作
- 动画的基础设施和 API。这将类似于 CSS 中动画的工作方式,部分工作不仅要移植我们现有的 CSS 动画支持,还要将堆栈切换动画、揭示器、进度条和微调器移植到新的框架中。Emmanuele 正在做这项工作。
- 完成菜单/弹出窗口的重做。有些人尝试了新的弹出菜单栏。反馈是我们应该回到嵌套子菜单,至少对于菜单栏,并推进放弃菜单,因为菜单的一些特殊方式(例如保持向上的三角形、滚动)很难保持工作(或保持良好的工作状态)。Matthias 将在 Guadec 之后回到这项工作。
- 快捷方式 – 将助记符、加速器和键盘绑定替换为事件控制器。有一个相当完整的分支,其中包含代码和 API,几个人已经参与其中;欢迎大家帮助审查和测试它。
- 新的拖放 API 需要完成。
好消息是,此列表相当短,并且大多数项目旁边都有名称。坏消息是,每个项目都需要大量的工作。因此,在我们合并所有这些项目之前,承诺 4.0 版本的紧凑时间表并不是一个好主意。因此,以下内容是暂定的,但(我们希望)在某种程度上是现实的
- 今年年底前发布另一个 GTK 3.9x 快照
- 在 2020 年春季与 GNOME 3.36 大致同时发布功能完整的 3.99 版本
- 在 2020 年秋季与 GNOME 3.38 大致同时发布 4.0 版本
不可避免地,我们也讨论了其他一些希望拥有的东西。这些都不在 GTK4 的路线图上;但是,如果有人出现做这项工作,它们可能会发生
- 一个“小部件存储库”或“hig”库,以便不会让 GTK 负担过多的特定或实验性小部件
- 一个“UI 设计器”小部件。这也可以放在一个单独的库中
- 更好地支持拆分标题栏和状态转换
我们还讨论了 GTK 本身之外的事情,这些事情会阻止应用程序移植到 GTK4。这包括常用的库,如 GtkSourceView、vte 和 webkitgtk,所有这些都需要 GTK4 端口,才能移植依赖于它们的应用程序。其中一些工作已经在进行中;但欢迎大家在这方面提供任何帮助!
GTK4 移植的另一个潜在障碍是平台支持。GL 渲染器在 Linux 上运行良好;Vulkan 渲染器需要一些修复。在 Windows 上,我们目前使用 Cairo 回退,这对于 4.0 可能就足够了。或者,我们可以合并现有工作,以将 GL 渲染器与 ANGLE 一起使用。在 OS X 上的情况不太乐观,我们在那里没有可用的后端;如果你想在这里帮助我们,第一步仍然是将 GDK 后端调整为 GDK 中的更改。
黑客时间
下午,会议室从讨论转向了黑客活动,人们的笔记本电脑上可以看到各种与 GTK 相关的工作正在进行中:加快 GtkBuilder 模板加载的工作、嵌套的弹出菜单、一个半成品 GtkSourceView 端口。
您有望很快在 GTK 主分支中看到这些(和其他)。
很棒的总结!
可能是一个错字:2020 年而不是 2019 年的 Gnome 3.36 和 3.38。
Gtk4 的炒作列车正在积蓄动力。虽然我自己目前由于 webkitgtk 的原因而无法开始迁移 :(
我有点失望,因为没有讨论自定义 Wayland 表面,因为 GTK4 当前删除了该功能。这阻止了我将我的 2 个项目移植到 GTK4。
@Scoopta:我们根本不可能讨论我们一无所知的事情。你需要“自定义 Wayland 表面”做什么?你试图实现什么?
@Emmanuele 我指的是这个合并https://gitlab.gnome.org/GNOME/gtk/merge_requests/713 我使用自定义表面用于 https://hg.sr.ht/~scoopta/rootbar 和 https://hg.sr.hg/~scoopta/wofi
@Scoopta:我假设你阅读了该合并请求中的整个讨论。我的建议是打开一个问题(对关闭的合并请求发表评论是毫无意义的),然后开始讨论这个 API 应该涵盖哪种用例,以及一个原型 API。关心特定用例或特定功能的人有义务来找我们并进行讨论;我们当前的任务列表已经足够长了,可以修复那些已经有用例和原型的东西。
您好,感谢您提供有关 GTK4 进展的反馈。
我担心在 GTK4 中看不到剩余的辅助功能问题,认为应该在发布之前解决:https://gitlab.gnome.org/GNOME/gtk/issues/1739
此致。
@alex:我计划花一些时间在 GTK4 中处理 a11y,作为我为 GNOME 基金会付费工作的一部分,主要是了解其他平台如何实现现代、安全的辅助功能,并在 GTK 内部提供类似的实现,而无需通过 ATK。这可能需要在 Linux 上使用 AT-SPI3,可能采用一个不那么糟糕的“让我们在一个私有 DBus 通道之上重新实现 CORBA,以避免将性能降低到停顿状态”的方法,以及一个适用于 AT 客户端的体面、现代的 API。我在 GUADEC 上与各界人士谈论过这个问题。
一旦我有了 GTK4 中 a11y 的一套要求和一个草案,我将确保召集各方利益相关者——合成器开发人员、AT 开发人员和工具包开发人员——以便我们可以开始讨论,并希望从当前的灾难(a11y)中前进。