Jan Dolinár

Good point, I didn't think of that. Here is an updated patch.

I have tried to figure out whether the suggested change would affect X11 users (by running with GDK_BAKCEND=x11 on wayland, I don't have Xorg installed). Unfortunately, it seems it would break current behaviour on X11. The problem is, that the behaviour of gdk_window_get_origin is not consistent accross platforms. I have looked through its implementation and found out it's probably documented behavior, see the comment here: https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/wayland/gdkwindow-wayland.c#L3671-3705...

Thanks for the hint Neil, it proved very helpful. I tracked it down to a single condition in SetPositionRelative: if (sizey > rcMonitor.height || oy < rcMonitor.y) { oy = rcMonitor.y; I believe that the oy value is correctly calculated in coordinates relative to the window (I gess the "o" stands for offset, rigt?), so comparing it to rcMonitor.y, which is in global coordinates is wrong. It triggers every time, since the offset is always within the 1080px high screen, which is less than the 1080px...

After bit more reconnaissance it seems that the problem is not actually in showing the window, but in its positioning and in my sway config. I have the displays configured in sway config like this: output HDMI-A-2 mode 1920x1080 pos 0 0 output eDP-1 mode 1920x1080 pos 0 1080 eDP-1 is internal display of my notebook, HDMI-A-2 is a HDMI port I use to plug in external monitor at work. I have the internal monitor offseted (to be below the external monitor). The code in ListBoxX::GetDesiredRect() does...

Autocompletion not working on wayland