On Tue, Nov 20, 2018 at 8:06 AM John Ralls <jra...@ceridwen.us> wrote:
> I’m working on GdkQuartz to bring it up to date with the rest of Gdk. I’m > starting with GdkDisplay and GdkMonitor mostly because of > https://gitlab.gnome.org/GNOME/gtk/issues/1312. This question may also > bear upon https://gitlab.gnome.org/GNOME/gtk/issues/1029 as well as other > pointer coordinate issues some users have reported on downstream > applications. > > Under the old GdkScreen regime Gdk had a “root window” with 0,0 in the > upper left corner of the upper-left-most monitor and all point values are > unsigned, increasing down and to the right. Quartz uses a different > coordinate system with the origin at the bottom-left corner of the > “primary” monitor with point values increasing up and to the right. > Monitors placed below or to the left of the “primary” monitor will have > negative coordinates. gdkscreen-quartz and gdkwindow-quartz have conversion > code to create a fake root window and to translate between the two > coordinate systems. > > The new GdkDisplay/GdkMonitor regime does away with the root window and > introduces gdk_display_get_monitor_at_point and > gdk_display_get_monitor_at_window that iterate over the list of active > monitors testing for whether the coordinates of the point or window lie > inside each monitor’s work area. That’s great, it’s similar to the way > Quartz works... but are there any assumptions made about coordinates that > need translation between Gdk and Quartz? > > Yes, we haven't fully resolved this, in particular with respect to hi-dpi. It is still an open issue on the gtk4 roadmap: https://gitlab.gnome.org/GNOME/gtk/issues/1106
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
