<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - Wayland: gdk_screen_get_monitor_at_window() unreliable under Wayland" href="https://bugzilla.gnome.org/show_bug.cgi?id=766566#c22">Comment # 22</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - Wayland: gdk_screen_get_monitor_at_window() unreliable under Wayland" href="https://bugzilla.gnome.org/show_bug.cgi?id=766566">bug 766566</a> from <a href="page.cgi?id=describeuser.html&login=jadahl%40gmail.com" title="Jonas Ådahl <jadahl@gmail.com>"> Jonas Ådahl</a> <pre>(In reply to Olivier Fourdan from <a href="show_bug.cgi?id=766566#c21">comment #21</a>) > (In reply to Jonas Ådahl from <a href="show_bug.cgi?id=766566#c18">comment #18</a>) > > Yea, it makes sense to keep it private, so that no new place starts to rely > > on something that isn't reliable. > > But again, there is no reason for it to be unreliable, we "just" have to add > the relevant missing protocol bits to make it reliable. > > > Should add the "get_monitor_at_window" to the list of things to deprecate > > for GTK4 I guess. > > Yet I am not entirely convinced "get_monitor_at_window()" is not useful, > even more when there is no global coordinates like in Wayland, it's pretty > much the only remaining way to identify the monitor, unless we reckon > identifying the monitor is not something clients shouldn't be able to do. True. We should figure out the use cases where it is needed and see what protocol would fit that use case. For example the adaptive-menu-height would not directly benefit from from knowing the wl_output since the work area is still unknown, but could use for example a "max size" hint as part of the post-position configuration. We wouldn't be able to just use a "you're mostly here" kind of monitor state, because if a menu is opened on a monitor which a window is a overlapping a bit less, we'd still use the wrong monitor for deciding the size. As for toplevels, I'm guessing it mostly matters before being mapped, and then it won't know exactly where either, but I suppose that could also be done as some kind of max size configuration event as part of the xdg_toplevel configuration. So in the end, I'm not sure we'd end up with just a simple "get monitor where its mostly at" kind of API. > > Meanwhile: > > <a href="attachment.cgi?id=328173&action=diff" name="attach_328173" title="[PATCH] wayland: Make gdk_wayland_window_get_wl_output() private">attachment 328173</a> <a href="attachment.cgi?id=328173&action=edit" title="[PATCH] wayland: Make gdk_wayland_window_get_wl_output() private">[details]</a> <a href='review?bug=766566&attachment=328173'>[review]</a> [review] has been pushed as commit <a href="https://git.gnome.org/browse/gtk%2B/commit/?id=0b58c96">0b58c96</a> - > wayland: Make gdk_wayland_window_get_wl_output() private Thanks! I think its the safest for now at least.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>