Skip to content

node: More reliably detect the right gtk4 window

Michael Weghorn requested to merge michaelweghorn/accerciser:michaelweghorn/more_reliably_detect_gtk4_window into master

Since Gtk 4 doesn't support global screen coords,

commit 238db8fbb85bb2b2bdb1f36a0fd502b3236051b6
Author: Michael Weghorn <m.weghorn@posteo.de>
Date:   Thu Oct 5 18:22:13 2023 +0200

    node: Calculate screen coords for gtk4 apps

introduced a mechanism to calculate screen coords from the window-relative coords and the window coords retrieved via Wnck.

Refine the logic to find the correct window: When multiple windows with the same name exist, prefer the (first) one whose size matches that of the accessible toplevel object.

This e.g. makes highlighting for the following case work as expected:

  • start gtk4-demo
  • run the "Hypertext" example -> a second window with window title "Hypertext" shows up for the actual example
  • click on the a11y object of that second window in Accerciser's tree view of the a11y hierarchy

Now, the correct area is highlighted on screen (at least on KDE Plasma X11). Previously, the first gtk4-sample window (that also has "Hypertext" as window title) was considered the top-level window used for the calculation of the object's screen position.

Use a regex when matching the window names to handle 2 special cases seen at least on KDE Plasma X11 with the gtk4-demo use case described above:

  • When matching the name, also consider windows for which libwnck/the window manager (?) has appended a specific suffix to distinguish multiple windows with the same name. For the above "Hypertext" example, libwnck reported "Hypertext" for the first window, but "Hypertext <2>" for the second window, while both were using "Hypertext" in the a11y hierarchy, so the correct window wouldn't be found otherwise.

  • Accept an additional trailing Left-to-Right Mark (U+200E) in the application name, as that was seen in the libwnck-reported name, too.

Merge request reports