Re: GdkScreen size-changed and gdk_monitor_get_workarea problem
- From: Bastien Nocera <hadess hadess net>
- To: "Sebastian Geiger (Lanoxx)" <lanoxx gmx net>, gtk-devel-list gnome org
- Subject: Re: GdkScreen size-changed and gdk_monitor_get_workarea problem
- Date: Thu, 08 Nov 2018 12:53:46 +0100
On Thu, 2018-11-08 at 12:34 +0100, Sebastian Geiger (Lanoxx) wrote:
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.
I'd start with filing a bug against mutter (I'm not sure metacity is
still maintained), and see whether the GDK API documentation should be
amended after discussing it there.
Unless you're writing a panel of sorts, I don't think end-user
applications should use this API in any case, with the window manager
taking care of the window layout.
Cheers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]