随着新兴的 显示 服务器 技术的发展,工具包有时需要调整它们实现其功能的方式。其中一组需要调整的功能是如何让 GTK+ 定位弹出窗口,例如菜单、弹出框和工具提示,以使其放置在显示器的工作区域内。
在过去,当 GTK+ 想要定位菜单时,它会首先查找菜单父窗口的全局位置。然后它会查找所有已连接显示器的工作区域。有了给定的工作区域、父窗口的全局位置以及相对于父窗口的预期菜单位置,GTK+ 将使用一个巧妙的算法来计算菜单的合理位置,使其对用户可见。例如,如果“文件”菜单没有足够的空间在父菜单项下方弹出,则 GTK+ 会将其重新定位到父菜单项上方。
由于 各种 原因,“全局窗口位置”的概念已从这些新的显示服务器技术中的客户端中移除,这意味着我们无法再在 GTK+ 中使用我们巧妙的算法。
但是我们仍然希望我们的菜单、工具提示、弹出框等对期望与之交互的用户完全可见,那么我们如何在不知道窗口位置的任何信息的情况下确保这一点呢?
为了在 GTK+ 中解决这个问题,我们必须解决一些问题。
- 定位逻辑需要移到 GDK 中,同时仍然允许 GTK+ 在初始预期位置最终超出工作区域时影响菜单定位的行为。
- 不同的 GDK 后端可能会 以不同的方式 执行操作。
- 某些类型的窗口需要知道它最终所处的位置,以便它们可以调整自己的绘制方式。
- 有些窗口只是想尽可能地占用空间(例如,一个选项过多的菜单不应该比屏幕高)。
去年,William Hua 和我开始 致力于 将 GTK+ 带入无全局位置菜单窗口的美好未来。在提出了一系列实现此目标的补丁之后,关于这样一个 API 实际应该是什么样子开始了讨论。在 200-300 条评论之后,我们决定应该面对面讨论这个问题。
于是有了在多伦多的 GTK2016!
在黑客马拉松中,我们有机会坐在白板前,讨论不同的用例、需要解决的问题、后端如何工作,最终我们提出了一个 API。
我们提出的 API 如下
从 GDK 方面,我们引入了一个新的函数(目前没有任何 API 稳定性承诺;它目前仅供 GTK+ 使用)gdk_window_move_to_rect(),它接受一组描述应用程序希望如何相对于某些父表面放置其窗口的参数。它接受
- 一个 transient-for 窗口
要放置的父窗口,相对于父窗口上的一个锚点矩形,弹出窗口或菜单通常希望相对于父窗口上的一个矩形放置,例如,右键单击上下文菜单应该从单击时指针所在像素的某个方向展开,或者文件菜单应该放置在父窗口上的文件菜单项矩形的下方或上方。
- 一个矩形锚点重力
不同的弹出菜单可能希望在特定方向打开。例如,垂直菜单可能希望向右打开,而水平菜单可能希望向下打开。
- 一个窗口锚点重力
不同的弹出菜单可能希望以不同的方式与父锚点矩形的锚点矩形对齐。例如,虽然组合框可能希望在某个方向展开,但它希望覆盖它展开的矩形。
- 一个锚点提示
不同的弹出菜单希望以不同的方式调整其位置;有些希望从父锚点矩形在不同的方向展开,有些希望只是滑动到可见位置,有些希望调整大小,而有些则希望将这三者结合使用。
- 一个矩形锚点偏移量
偏移量只是一个用于常见用例的微调因子,其中弹出菜单会相对于锚点偏移其位置。
通过让 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 查看未来如何放置菜单的所有详细信息。