Linux/Wayland new feature: Accept native parent window handle

[btzy]

#136 added support for passing a parent window handle, ensuring that the file dialog always stays on top of the parent window and other platform-specific effects. Support was not added for Wayland then, due to implementation complexity and the scarcity of good documentation for the unstable xdg-foreign protocol for Wayland. This PR adds this missing support, using the xdg_foreign_unstable_v1 protocol. (There is a xdg_foreign_unstable_v2 protocol, but it seems that all platforms supporting v2 also support v1.)

Under Wayland, a client cannot simply hand over a window handle to another client. The sending client calls a Wayland function that takes a window handle and returns a string token representing it (known as exporting the window), and then sends that token over to the receiving client. The receiving client then calls another Wayland function that takes the string token and returns a "foreign" window handle (known as importing the window). The receiving client can then make this "foreign" window the transient parent of its own windows. On Portal, the receiving client is a different process (the xdg-desktop-portal implementor); on GTK, the receiving client is wrapped in a GdkDisplay on the same process.

Due to the need to call a Wayland function, Native File Dialog Extended now depends on the wayland-protocols repository (https://gitlab.freedesktop.org/wayland/wayland-protocols) as a git submodule (checked out to v1.47, but it shouldn't really matter much since Wayland protocols are meant to be backward compatible). New CMake feature flags NFD_X11 and NFD_WAYLAND have also been added to control whether the library is built with X11 and Wayland support respectively. By default both X11 and Wayland are supported, and this will lead to a runtime dependency on libwayland-client.

The GTK implementation has also been adjusted somewhat to do things more correctly. Before the dialog is realized (i.e. is made into a real GdkWindow), it needs to be told the GdkScreen to use (which can be any GdkScreen that uses the correct display server (X11 or Wayland)), but we can only set the transient parent after realization.

• Portal
• GTK

Note: Under XWayland, window parenting does not work (it behaves as if you did not pass a parent window handle). It behaves this way on both GTK and Portal. I'm not sure why, but since this is the behaviour for Portal, it's probably a limitation of XWayland.

Note: On GLFW < 3.4, the GLFW library on Linux either comes with X11 or Wayland, but not both. This means that on a system that supports both X11 and Wayland, an application using GLFW < 3.4 will only work with one display server.

[btzy]

Initially I said ...

This PR will currently cause NFDe to have a runtime dependency on wayland-client, which provide the exporting and importing APIs. This is undesirable as it will cause applications using NFDe to fail to start on a pure X11 system.

... but I'm not really sure this is actually a concern now. Is it the package manager's responsibility to serve the correct package?

Turns out this is not a concern, and most Linux applications simply link both X11 and Wayland libraries.

[wolfpld]

(There is a xdg_foreign_unstable_v2 protocol, but it seems that all platforms supporting v2 also support v1.)

This is not true.

$ WAYLAND_DEBUG=1 ./tracy-profiler 2>&1|grep exporter
[2306841.693] {Default Queue} wl_registry#2.global(35, "zxdg_exporter_v2", 1)
[2306861.541] wl_registry#20.global(35, "zxdg_exporter_v2", 1)
[2306879.993] wl_registry#24.global(35, "zxdg_exporter_v2", 1)
[2306933.552] {Default Queue} wl_registry#36.global(35, "zxdg_exporter_v2", 1)

(KDE 6.7.2)