本周 GTK+ – 16

在过去的这一周里,GTK+ 的主分支有 32 次提交,增加了 5125 行代码,删除了 4393 行代码。

规划和状态
  • Matthias 发布了 GTK+ 3.21.5,这很可能是 3.22.0 版本发布前的最后一个开发者快照。
  • GTK+ 的路线图可在 维基上找到。
值得注意的变更
  • 为了使用 xdg_shell 协议的 v6 版本,GTK+ 需要 1.7 版本的 Wayland 协议定义。
  • GtkScrolledWindow 现在可以选择将其子元素的首选自然大小传递给父元素。

修复的错误

  • 770550 gtkplacessidebar: 修复信号编组
  • 770458 GtkAboutDialog 在长鸣谢列表和 GtkScrolledWindow 中的问题
  • 770307 关闭 glade 项目时崩溃
  • 770624 [补丁] 修复拼写错误。
  • 770745 wayland: 当应用程序尝试错误地映射弹出窗口时发出警告
  • 769498 滚动条损坏
  • 770703 修复在 GtkListBox 上使用 page-down 时崩溃的问题
  • 770614 在高对比度主题中,当值 = 0 时 GtkScale:警告:为节点高亮分配负的内容宽度/高度
  • 770849 GtkLabel 的 padding 损坏
  • 766569 为 GTK_SCROLL_NATURAL 子元素提供更好的尺寸请求
参与进来

有兴趣参与 GTK+ 的工作吗?请查看 新手的错误列表,并加入 irc.gnome.org 上的 IRC 频道 #gtk+。

GTK+ 中的版本控制和长期稳定性承诺

本文中提出的计划取代了 2016 年 6 月在多伦多 GTK+ 黑客马拉松之后公开的计划。

本月,GTK+ 团队将发布一系列长期稳定版本中的第一个。这将使 GTK+ 更加可预测和可靠,同时不会阻碍未来的 GTK+ 改进。

这些计划是在自去年 6 月在多伦多举行的 GTK+ 黑客马拉松制定初步计划以来,与各种利益相关者讨论的结果。

背景

自 2002 年发布 2.0 版本以来,GTK+ 一直遵循相当简单的版本控制方案

  • 主版本指定通用 API 版本
  • 次版本指定开发周期(如果为奇数)和稳定周期(如果为偶数)
  • 微版本指定错误修复更新

任何在 GTK+ 中引入的 API 都保证存在到下一个主版本;在开发周期中引入的 API 保证在稳定周期开始后保留。稳定周期不提供新功能或新的 API。

这个方案很好地为我们服务,但它的问题在 3.x 系列中变得越来越明显,特别是当与 6 个月、基于时间的开发周期相结合时。在 2.x 周期中,GNOME 应用程序中的新功能被迫出现在额外的库中,因为工具包太复杂或移动太慢。自 3.0 以来,GTK+ 的开发步伐一直在加快。GTK+ 已被置于中心位置,每六个月都会引入新的小部件和新功能。然而,为了实现这些新的小部件和功能,工具包的一些内部结构一直处于变化状态。

从 GNOME 的角度来看,GTK+ 一直是一个相对稳定,但不断变化的目标,因为 GNOME 开发人员和 GTK+ 开发人员可以共享反馈和提案,并快速跟上内部变化。另一方面,从社区的角度来看,跟踪 GTK+ 的开发更加痛苦。GNOME 项目之外的应用程序开发人员很难了解工具包中的哪些更改会影响他们的代码库。GTK+ 团队试图改进其沟通渠道,但在开发周期中发布有关更改的博客对于更广泛的 GTK+ 用户社区来说还不够。

长期稳定的 GTK+ 版本

GTK+ 有三个主要利益相关者:希望功能和 API 稳定的版本的应用程序开发人员;希望访问 GTK+ 开发版本以便快速引入新功能的桌面开发人员(包括大多数 GNOME 项目);以及 GTK+ 团队本身,它需要在较长的开发周期中能够迭代库的内部结构。

引入长期稳定的 GTK+ 版本旨在确保 GTK+ 在这些受众之间取得良好的平衡。特别是,应用程序开发人员将能够访问一个稳定的平台,该平台仍然可以访问在 3.x 系列期间开发的新 GTK+ 功能,例如 CSS 样式、触摸屏支持、HiDPI 显示屏支持、Wayland 支持、新小部件、GTK+ 检查器等等。

GTK+ 将继续发布主版本、次版本和微版本。一旦新功能稳定下来,就会发布新的主版本,预计大约每 2-3 年一次。当升级到新的主版本时,将删除已弃用的 API。之后,此 API 系列将被视为稳定。新的次版本可能会引入新的小部件,或更新 GDK 后端中的窗口系统协议的实现,但不允许额外的功能或主题更改。虽然以前每六个月发布一次次版本,但现在它们将在必要时生成。我们还将至少三年内继续进行错误修复和安全问题的微版本发布。此后的维护可能会继续,具体取决于可用的志愿者资源数量。具有长期支持发布周期(超过三年)的操作系统发行商可能希望与 GTK 团队联系,以建立向后移植的策略。

长期稳定系列中的更新将是 ABI 稳定的。除了这些稳定系列之外,GTK+ 的开发将在半稳定的开发系列中继续进行。这些开发版本将在次版本之间包含一些 API 更改,但更改将尽可能受到限制。这是我们期望 GNOME 应用程序采用的路径,但其他应用程序开发人员如果希望访问最新功能,可以选择此选项,但代价是每个次版本可能需要进行一些移植工作。

虽然 GTK+ 团队保留在开发系列中更改 API 的权利,但这并不意味着整个 GTK+ API 会在每个版本中不断破坏;只有特定的,并且希望很少使用的 API 部分可能会更改,如果更改过于广泛,它们很可能会延迟到下一个主要开发周期。我们将确保提前充分沟通这些更改。

新的版本控制方案

新的 GTK+ 版本控制方案是我们至今遵循的“语义版本控制”方案的修改。一旦新的主要稳定版本发布,开发周期就开始,我们将

  • 将 pkg-config 文件更新到新的主版本,以允许 GNOME 开发人员在开发期间以新的 API 为目标
  • 将现有的主版本保持在相同的数字
  • 将次版本更新为 90 以指示开发版本

例如,在 3.22.0 版本发布后以及新的开发周期开始时,pkg-config 文件将被称为 gtk+-4.0,并且 configure.ac 文件中的版本将设置为 3.90

每六个月将发布一个新的偶数开发版本,例如 x.90x.92x.94,直到 GTK+ 团队确信新的 API 和功能集是稳定的。这些次版本中的每一个都会增加共享库的 soname,以确保自动化工具可以获取最终的更改并通知发行商和维护人员。一旦我们达到 API 和功能集足够稳定以供更广泛的社区使用的程度,我们将发布一个新的主版本 (x + 1).0 并声明 API 稳定。

一旦发布了这个零版本,将创建一个新的稳定分支,并且主分支将升级到下一个点 90 版本并开始新的开发周期。点 90 版本将与之前的稳定版本并行安装。

gtk-versioning-scheme

3.22 将是 3.x 系列的最后一个次版本,新的版本控制方案将从 3.90 开始生效。3.22 版本在方案中是不规则的,因为它是一个长期稳定版本,但不会收到进一步的次版本,并且没有 .0 版本号。这是一个必要的过渡步骤。

下一步是什么

关于这些计划的更多细节,包括针对库开发者和发行版打包者的具体信息,将在后续的博客文章中发布。GTK+ 开发博客也将继续提供有关 GTK+ 本身技术变更的更新,以便提供关于每个即将到来的主要版本中将有哪些变更的信息。

我们对这些计划感到兴奋,并希望它们能开启 GTK+ 的新时代,在这个时代中,应用程序开发者可以对我们的平台更有信心,同时仍然允许我们在 3.x 系列中看到的快速开发步伐。

本文中提出的计划取代了 2016 年 6 月在多伦多 GTK+ 黑客马拉松之后公开的计划。

本周 GTK+ 进展 – 15

在过去的一周里,GTK+ 的主分支有 60 次提交,新增 10838 行代码,删除 6850 行代码。

规划和状态
  • 我们即将发布 GTK+ 3.22 版本,以配合 GNOME 3.22 的发布。
  • Emmanuele 在 他的 GSK 分支中实现了一个更全面的混合部件树回退路径。
  • Timm Bäder 在 GUADEC 上由 Jussi Pakkanen 完成的将构建系统初步移植到 Meson 的工作基础上进行了改进
  • GTK+ 的路线图可在 维基上找到。
值得注意的变更
  • Carlos Garnacho 合并了他为 Wayland GDK 后端实现图形平板电脑支持的分支;更多细节请参考他的博客
  • Jonas Ådahl 将 GDK 移植到了 Wayland xdg_shell 协议的第 6 版,他还修复了 Wayland 上沙箱门户创建的瞬态窗口的行为。

修复的错误

  • 770236 gtkbindings: 添加 gtk_binding_entry_add_signal() 的示例
  • 770026 wip/wayland-tablet-v2 的审查意见
  • 770332 创建新标签后,Notebook 箭头图标颜色错误
  • 769937 wayland: 移植后端以使用 xdg-shell 不稳定版 v6
  • 764413 Wayland: 不可全屏的 gtk+ 应用程序可以被全屏化
  • 770374 当列宽较小时,Gtk Treeview Editable 会超出列宽
  • 770550 gtkplacessidebar: 修复信号编组
  • 770458 GtkAboutDialog 在长鸣谢列表和 GtkScrolledWindow 中的问题
  • 769788 修复 Wayland 上 flatpak 门户的堆叠顺序
参与进来

有兴趣参与 GTK+ 的工作吗?请查看 新手的错误列表,并加入 irc.gnome.org 上的 IRC 频道 #gtk+。

本周 GTK+ 进展 – 14

在过去的两个星期里,GTK+ 的主分支有 48 次提交,新增 4967 行代码,删除 3798 行代码。

规划和状态
  • 由于大多数 GTK+ 开发人员都在 GUADEC,因此我们跳过了上周的更新。
  • 我们对新的发布管理和版本控制方案进行了非常富有成效的讨论;期待在本博客上发布完整公告。
  • GSK 在 GUADEC 期间进行了审查,并且正在进行将部件转换为新的保留渲染 API 的工作;该 API 不会合并到 3.22 中,目的是提高渲染性能,解决在移植过程中发现的最后一个 API 问题,尤其是避免最后一刻破坏在 GTK+ 窗口之上使用自己的渲染的应用程序,如 Firefox 和 LibreOffice。
  • Carlos Garnacho 一直在将 Wayland 后端移植到新的平板电脑协议;各种更改已经登陆到主分支,并且大部分审查过程都在bug 770026 中。
  • bug 768081 中,支持 Windows 后端 HiDPI 显示屏的工作正在进行中。
  • GTK+ 的路线图可在 维基上找到。
值得注意的变更
  • Andreas Pokorny 一直在更新 GDK 的 Mir 后端,以改进 GTK+ 应用程序的集成。
  • Timm Bäder 向 GtkPopover 添加了两个新方法,gtk_popover_popup()gtk_popover_popdown();这两个新方法实现了动画过渡,而调用 gtk_widget_show()gtk_widget_hide() 将立即显示或隐藏 GtkPopover。 随着这两个新方法的添加,GtkPopover:transitions-enabled 属性现在是多余的并且已被弃用。

修复的错误

  • 769603 gtk+-3.20.8: ld.gold 存在下链接问题 – 构建失败: ./.libs/libgdk-3.so: error: 对 ‘shm_open’ 的引用未定义
  • 769601 gtk-question-index.html 中的 faq 存在死链接
  • 769568 修改日期显示不正确地包装日历日期(并且与 GTK2 和 Nautilus 不一致)
  • 768138 更新 GDK-Mir 后端以修复一些问题
  • 769706 向 GtkPopover 添加显示/隐藏 API
  • 769402 wayland 上的菜单定位出现回归
  • 768017 [Wayland] 通过访问键(助记符菜单项)打开的菜单会立即隐藏
参与进来

有兴趣参与 GTK+ 的工作吗?请查看 新手的错误列表,并加入 irc.gnome.org 上的 IRC 频道 #gtk+。

本周 GTK+ 进展 – 13

在过去的一周里,GTK+ 的主分支有 29 次提交,新增 4141 行代码,删除 3230 行代码。

规划和状态
值得注意的变更
  • Ruslan Izhbulatov 修复了 Windows 上键盘布局和死键处理的两个长期存在的问题。Windows 上的 GTK+ 应用程序现在的行为应该更符合平台的其余部分,尤其是在美国国际键盘上。这些更改已应用于主分支,但在进一步测试后,它们应被向后移植到 2.x 稳定分支。

修复的错误

  • 769287 GtkMenuToolButton:show-menu 发出两次,并破坏动态菜单
  • 769485 消除 g_test_expect_message() 的使用
  • 712760 Clang 静态分析修复
  • 769451 自 2016 年 7 月 26 日以来,Debian Unstable 中的 3.21 (master) 构建失败
参与进来

有兴趣参与 GTK+ 的工作吗?请查看 新手的错误列表,并加入 irc.gnome.org 上的 IRC 频道 #gtk+。

本周 GTK+ 进展 – 12

在过去的一周里,GTK+ 的主分支有 28 次提交,新增 1868 行代码,删除 1422 行代码。

规划和状态
  • GTK+ 的路线图可在 维基上找到。
值得注意的变更
  • Georges Basile Stavracas Neto 将之前私有的 GtkShortcutLabel 部件(快捷方式窗口使用)纳入了公共 API;该部件将用于 GNOME 控制中心的键盘选项,并且可以被允许编辑自身键盘快捷方式的应用程序使用,例如 PiTiVi。

修复的错误

  • 768999 在 Xvfb 下运行时出现浮点数异常(除以零)
  • 768930 reftests:在运行测试时覆盖 GSETTINGS_SCHEMA_DIR
  • 760944 使用 Gtk 3.19+ 后,调整大小和几何图形(贴靠字符单元格)出现倒退
  • 755947 wayland:gnome-terminal 在平铺时未填充整个区域
  • 769047 GtkWidget <-> GtkStyleContext API 不明确
  • 769205 将 GtkShortcutLabel 公开为一个公共部件
  • 769004 3.21.4 中的 css 测试套件失败
  • 768902 使用 gtk_widget_override_font() 时字体太小
  • 769126 无法使用 Windows 10 触摸键盘在 GtkEntry 中输入星芒层字符
  • 769236 演示:修复构建失败
参与进来

有兴趣参与 GTK+ 的工作吗?请查看 新手的错误列表,并加入 irc.gnome.org 上的 IRC 频道 #gtk+。

本周 GTK+ – 11

在上周,GTK+ 的 master 分支提交了 22 次,新增 6199 行代码,删除 1763 行代码。

规划和状态
  • Matthias Clasen 发布了 GTK+ 3.21.4 和 GLib 2.49.4,这是两个新的开发者快照版本。
值得注意的变更
  • William Hua 开始将 菜单和弹出窗口的相对定位的补丁合并到 master 分支。
  • Lapo Calamandrei 对 Adwaita 中 GtkCalendar 的样式进行了小的视觉刷新。
  • Carlos Garnacho 更新了 GDK,以使用 Wayland 图形平板输入协议的 2.0 版本。
  • Matthias Clasen 更新了 GTK+,以选择使用 GLib 提供的新结构化日志 API。

 

修复的错误

  • 769003 Adwaita:GtkCalendar 对一年中的周使用了令人困惑的样式
  • 756579 GTK 应该让 GDK 定位菜单
参与进来

有兴趣参与 GTK+ 的工作吗?请查看 新手的错误列表,并加入 irc.gnome.org 上的 IRC 频道 #gtk+。

本周 GTK+ – 10

在上周,GTK+ 的 master 分支提交了 16 次,新增 2500 行代码,删除 2092 行代码。

规划和状态
  • Jonas Ådahl 和 William Hua 正在开发 功能分支,它为定位弹出窗口和菜单提供了一个新的声明式 API;您可以在上周五发布的博客文章中以及 bug 756579 上阅读相关内容。
值得注意的变更
  • Matthias Clasen 合并了 Philip Withnall 编写的 补丁,该补丁在 GLib 中实现了一个结构化日志 API。这项工作仍在进行中。
修复的错误
  • 768657 places-view:修复没有挂载或卷的位置的打开操作
  • 768659 gtk/gtkfilechoosernativeportal.c:不要使用 g_autoptr()
  • 768756 GtkFileChooserNativePortal 使用错误的响应 ID
参与进来

有兴趣参与 GTK+ 的工作吗?请查看 新手的错误列表,并加入 irc.gnome.org 上的 IRC 频道 #gtk+。

相对窗口定位的未来

随着新兴的显示服务器技术,工具包有时需要调整它们实现所提供功能的方式。其中一组需要调整的功能是 GTK+ 如何定位弹出窗口(例如菜单、弹出框和工具提示),以便将它们放置在监视器的工作区域内。

在过去,当 GTK+ 想要定位菜单时,它首先会查找菜单的父窗口的全局位置。然后它会查找所有连接的监视器的工作区域。有了给定的工作区域、父窗口的全局位置以及相对于它想要放置菜单的父窗口的预期菜单位置,GTK+ 将使用巧妙的算法来计算菜单的合理放置位置,以便用户可见。例如,如果文件菜单没有足够的空间在父菜单项下方弹出,则 GTK+ 会将其重新定位到父菜单项上方。

popup-flip

由于各种原因,“全局窗口位置”的概念已从这些新的显示服务器技术中的客户端中删除,这意味着我们不能再在 GTK+ 中使用我们巧妙的算法。

但是我们仍然希望我们的菜单、工具提示、弹出框等对于希望与之交互的用户来说是完全可见的,那么我们如何在不知道窗口定位的情况下确保这一点呢?

为了在 GTK+ 中解决这个问题,我们必须解决许多问题。

  • 定位逻辑需要移到 GDK,同时仍然允许 GTK+ 影响菜单定位的行为,如果最初的预期位置最终在工作区域之外。
  • 不同的 GDK 后端可能会以不同的方式执行操作。
  • 某些类型的窗口需要知道最终的位置,以便它们可以调整自身的绘制方式。
  • 有些窗口只是想尽可能多地占用空间(例如,具有太多选项的菜单不应高于屏幕)。

去年,William Hua 和我开始工作,使 GTK+ 进入无全局位置菜单窗口的光明未来。在提出一组执行此操作的补丁后,就开始讨论这样的 API 实际看起来像什么。经过 200-300 条评论后,我们决定最好亲自讨论一下。

进入多伦多的 GTK2016

在黑客马拉松中,我们有机会坐在白板前,浏览不同的用例、需要解决的问题、后端的工作方式,最终我们提出了一个 API。

william-draws-whiteboard(照片来源:Allison Lortie)

我们提出的 API 如下所示

从 GDK 方面,我们引入了一个新函数(到目前为止,没有任何 API 稳定性保证;它目前仅供 GTK+ 使用)gdk_window_move_to_rect (),它接受一组参数,描述应用程序希望如何将其窗口相对于某个父表面放置。它接受

  • 一个瞬态窗口

弹出窗口或菜单通常需要相对于父窗口上的一个锚点矩形进行定位。例如,右键单击上下文菜单应从单击时指针所在的像素位置向某个方向展开,而文件菜单应放置在父窗口上文件菜单项矩形的下方或上方。

  • 矩形锚点引力

不同的弹出菜单可能希望朝特定方向打开。例如,垂直菜单可能希望向右打开,而水平菜单可能希望向下打开。

  • 窗口锚点引力

不同的弹出菜单可能希望以不同的方式与父窗口锚点矩形对齐。例如,虽然组合框可能希望朝某个方向展开,但它会希望覆盖它展开的矩形。

  • 锚点提示

不同的弹出菜单希望以不同的方式调整其位置;有些希望从父窗口锚点矩形向不同方向展开,有些希望仅滑动到可见位置,有些希望调整大小,而有些则希望以上三种方式的某种组合。

  • 矩形锚点偏移

偏移只是一个微调因子,用于弹出菜单相对于锚点偏移其位置的常见用例。

通过让 GTK+ 提供其菜单所需定位方式的声明式描述,我们允许 GDK 根据显示服务器系统的设计以不同的方式实现实际定位。在 Mir 上,会创建一个 MirSurfaceSpec,而在 Wayland 上会创建一个 xdg_positioner 对象。在 X11、Windows 和 Mac OS X 上,后端可以使用可用的全局位置以及监视器工作区域,并像以前一样计算最佳位置。

然而,应用程序开发人员还不应直接使用此 API。通常需要的是创建一个菜单、一个弹出框、一个组合框,为此我们引入了一组参数和辅助函数,以使其非常方便。该 API 由几个新属性组成:

  • GtkMenu:anchor-hints – 定位策略。
  • GtkMenu:rect-anchor-dx – 水平偏移量,用于移动窗口。
  • GtkMenu:rect-anchor-dy – 垂直偏移量,用于移动窗口。
  • GtkMenu:menu-type-hint – 窗口类型 – 这仍然是必需的,以便 X11 后端可以通知窗口管理器正在映射的弹出窗口的类型。

还有一些函数:

  • gtk_menu_popup_at_rect () – 给定设置的参数,相对于父窗口上的给定矩形弹出菜单。
  • gtk_menu_popup_at_widget () – 给定设置的参数,相对于父窗口上的给定小部件弹出菜单。
  • gtk_menu_popup_at_pointer () – 给定设置的参数,相对于用户刚刚单击的位置弹出菜单。

有了这些函数,自定义小部件的开发人员现在可以以可移植的方式定位弹出菜单。到目前为止,GTK+ 自己的弹出菜单已经移植为使用这些新函数。在 Mir 后端中已经有一个基本的概念验证,并且 Wayland 实现正在进行中。

请访问 bug 查看将来如何放置菜单的所有详细信息。

gnome-sponsored-badge-shadow

GTK+ 本周动态 – 9

在上周,GTK+ 的主分支有 26 次提交,添加了 2416 行代码,删除了 180 行代码。

规划和状态
  • Emmanuele Bassi 正在研究他的 GSK 渲染分支,而 Alex Larsson 给出了 初步评论。Emmanuele 还写了一篇关于他的 GSK 工作的 博客文章
  • 关于发布策略的讨论仍在 gtk-devel-list 上进行;仍然欢迎意见。
  • William Hua 一直在重新构建 他的分支,使其基于新的、支持 Wayland 和 Mir 的弹出窗口定位 API,该 API 取代了通过全局坐标进行定位。
值得注意的变更
  • Matthias Clasen 在 GLib 和 GTK+ 中都实现了“portal”实现,用于协商访问沙箱外部的资源。你可以在 他的博客上阅读更多相关信息。
修复的错误
  • 768485 将窗口关闭空闲的优先级更改为 G_PRIORITY_DEFAULT
  • 768499 gtk+ 的门户支持
  • 768546 GtkTextView 的“move-viewport”信号的文档错误
参与其中

有兴趣参与 GTK+ 的工作吗?请查看 新手的错误列表,并加入 irc.gnome.org 上的 IRC 频道 #gtk+。