mutter

brl/mutter

Fork 0

Commit Graph

Author	SHA1	Message	Date
Marco Trevisan (Treviño)	6944839ab6	window-props: Read WM_TRANSIENT_FOR for override-redirect windows As per the Extended Window Manager Hints standard version 1.3 [1] an override-redirect window can set a transient-for window per compositing and app-matching purposes. So just read the WM_TRASIENT_FOR property also for such windows, adapting the error in case they are transient for another O-R window and adding a test to check such case. [1] https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472512128 https://gitlab.gnome.org/GNOME/mutter/merge_requests/920	2019-11-07 18:43:16 +00:00
Marco Trevisan (Treviño)	bacbbbd628	window-props: Don't set override redirect windows as top-level parent Java applications might use override-redirect windows as parent windows for top-level windows, although this is not following the standard [1]. In such case, the first non-override-redirect child window that is created was marked as being on_all_workspaces since the call to should_be_on_all_workspaces() returns TRUE for its parent, and this even though the on_all_workspaces_requested bit is unset. When a further child of this window was added, it was set as not having a workspace and not being on_all_workspaces, since the call to should_be_on_all_workspaces() for its parent would return FALSE (unless if it is in a different monitor, and the multiple-monitors workspaces are disabled). Since per commit 09bab98b we don't recompute the workspace if the on_all_workspaces bit is unset, we could end up in a case where a window can be nor in all the workspaces or in a specific workspace. So let's just ignore the transient_for bit for a window if that points to an override-redirect, using the x11 root window instead. Add a stacking test to verify this scenario (was failing before of this commit). Fixes https://gitlab.gnome.org/GNOME/mutter/issues/885 https://gitlab.gnome.org/GNOME/mutter/merge_requests/895 [1] https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472512128	2019-11-07 16:04:19 +00:00

Author

SHA1

Message

Date

Marco Trevisan (Treviño)

6944839ab6

window-props: Read WM_TRANSIENT_FOR for override-redirect windows

As per the Extended Window Manager Hints standard version 1.3 [1] an
override-redirect window can set a transient-for window per compositing and
app-matching purposes.

So just read the WM_TRASIENT_FOR property also for such windows, adapting
the error in case they are transient for another O-R window and adding a
test to check such case.

[1] https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472512128

https://gitlab.gnome.org/GNOME/mutter/merge_requests/920

2019-11-07 18:43:16 +00:00

Marco Trevisan (Treviño)

bacbbbd628

window-props: Don't set override redirect windows as top-level parent

Java applications might use override-redirect windows as parent windows for
top-level windows, although this is not following the standard [1].

In such case, the first non-override-redirect child window that is created
was marked as being on_all_workspaces since the call to
should_be_on_all_workspaces() returns TRUE for its parent, and this even
though the on_all_workspaces_requested bit is unset.
When a further child of this window was added, it was set as not having a
workspace and not being on_all_workspaces, since the call to
should_be_on_all_workspaces() for its parent would return FALSE (unless if
it is in a different monitor, and the multiple-monitors workspaces are
disabled).

Since per commit 09bab98b we don't recompute the workspace if the
on_all_workspaces bit is unset, we could end up in a case where a window can
be nor in all the workspaces or in a specific workspace.

So let's just ignore the transient_for bit for a window if that points to an
override-redirect, using the x11 root window instead.

Add a stacking test to verify this scenario (was failing before of this
commit).

Fixes https://gitlab.gnome.org/GNOME/mutter/issues/885
https://gitlab.gnome.org/GNOME/mutter/merge_requests/895

[1] https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472512128

2019-11-07 16:04:19 +00:00

2 Commits