Quartz Coordinates

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Quartz Coordinates

John Ralls-2
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?

Regards,
John Ralls



_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Quartz Coordinates

Gtk+ - Dev - General mailing list


On Tue, Nov 20, 2018 at 8:06 AM John Ralls <[hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list