随着新兴的显示服务器技术的发展,工具包有时需要调整其实现所提供功能的方式。其中一组需要调整的功能是 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 (),它接受一组参数,描述应用程序希望将其窗口放置在相对于某个父表面的位置的方式。它接受以下参数:
- 一个瞬态窗口
它要放置的父窗口,相对于父窗口上的一个锚点矩形,弹出窗口或菜单通常希望相对于父窗口上的一个矩形放置,例如,右键单击上下文菜单应该从单击时指针所在的像素向某个方向展开,或者文件菜单应该放置在父窗口文件菜单项矩形的下方或上方。
- 一个矩形锚点重力
不同的弹出菜单可能希望在特定方向打开。例如,垂直菜单可能希望向右打开,而水平菜单可能希望向下打开。
- 一个窗口锚点重力
不同的弹出菜单可能希望以不同的方式与父锚点矩形的锚点矩形对齐。例如,虽然组合框可能希望在特定方向展开,但它会希望覆盖它展开的矩形。
- 一个锚点提示
不同的弹出菜单希望以不同的方式调整其位置;有些希望从父锚点矩形向不同方向展开,有些希望只是滑动到可见位置,有些希望调整大小,而有些希望结合所有这三种方式。
- 一个矩形锚点偏移
偏移只是一个微调因子,用于弹出菜单相对于锚点偏移其位置的常见用例。
通过让 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 实现正在进行中。
请访问错误报告,查看有关如何在未来放置菜单的所有详细信息。
关于“相对窗口定位的未来”的一点想法
评论已关闭。