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

Reply via email to