Dear Bastien,
thanks for the reply. I will attach a sample next time.
My App runs with the X11 backend.
I was able to resolve the issue yesterday, and found that it was not
directly a Problem of GTK+.
The problem is, that the window manager computes the workarea
asynchronosly, presumably its handled in a g_add_idle callback.
When I tried to use get_geometry instead of get_workarea I was always
getting the correct values, but I specifically needed the workarea so
that was not helping.
My solution was then to register a filter function with
gdk_window_add_filter which listens for _NET_WORKAREA property changes
and then queue a g_add_idle callback which handles the change.
I tested the behavior with mutter and metacity and both had the same
problem.
I am not sure if this is by design, or a bug. However, I would like to
suggest that we add a small note to the documentation of the
monitor-changed signal and the size-change signal, stating that
values reported by gdk_monitor_get_workarea might arrive delayed.
Alternatively, fixing mutter and metacity would be my preferred solution
but would probably be more work and I have not the necessary knowledge
about mutter code to fix this myself.
Best Regards
Sebastian
On 07/11/18 20:08, Bastien Nocera wrote:
On Tue, 2018-11-06 at 21:35 +0100, Sebastian Geiger (Lanoxx) wrote:
Hi Gtk developers,
I am experiencing a wired issue and I am wondering if I am using the
API
in a wrong way of if there is a problem with Gtk.
On Wayland or X11?
<snip>
gdk_display_get_monitor_at_point and then gdk_monitor_get_workarea.
IIRC, the latter function isn't implemented in Wayland.
In the future, it would also probably be best if you could attach or
copy/paste a minimal test case, so folks on the mailing-list can try
your code, and see either if there are errors in the code, or those are
really bugs (or missing functionality).
Cheers
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list