marco/src, branch 1.26 MATE default window manager tabpopup: Use more contrasting background when not composited 2023-10-24T08:58:21+00:00 Colomban Wendling cwendling@hypra.fr 2023-10-04T08:42:54+00:00 7a017ddaeb4921663f6d8211d10d2b6c6672f2ff When composited, the tab popup uses an OSD style which typically has a dark background, so we use a light background highlight color. However, when not composited the popup uses a light color and should thus use a dark highlight. This was done for the workspace popup, but not for the window one, leading to the highlight being hardly visible in several themes. 
When composited, the tab popup uses an OSD style which typically has a
dark background, so we use a light background highlight color.
However, when not composited the popup uses a light color and should
thus use a dark highlight.  This was done for the workspace popup, but
not for the window one, leading to the highlight being hardly visible
in several themes.
ui/tabpopup: likewise only enable compositing code if available. 2023-10-24T08:58:14+00:00 Mihai Moldovan ionic@ionic.de 2023-07-28T18:27:28+00:00 fdfc8bdd01242a38d87684b9c5e80e06edd2adad 






ui/frames: check that compositing is not only requested, but also available.
2023-10-24T08:58:13+00:00

Mihai Moldovan
ionic@ionic.de

2023-07-28T18:24:57+00:00

a67e582bc96aac4a779b0fe28e7a005ca166bd03

Enabling code that is supposed to be used in compositing conditions is
harmful if compositing is not actually available. Just checking the
preference is not enough to make sure that compositing is available -
the X server might be missing crucial extensions for compositing to
work, which in turn correctly disables the internal compositor.

The end result is graphical issues like black borders around windows in
such situations.

Make sure that compositing is both requested AND available to fix this
bug.





Enabling code that is supposed to be used in compositing conditions is
harmful if compositing is not actually available. Just checking the
preference is not enough to make sure that compositing is available -
the X server might be missing crucial extensions for compositing to
work, which in turn correctly disables the internal compositor.

The end result is graphical issues like black borders around windows in
such situations.

Make sure that compositing is both requested AND available to fix this
bug.







Fix losing title of windows with a 3 or 4 bytes first character
2023-10-24T08:57:17+00:00

Colomban Wendling
cwendling@hypra.fr

2023-07-18T11:04:54+00:00

a938884530839152c9854dd0d8248b36c3c2e3fd

Fixes #757.





Fixes #757.







Show correct window title when owned by superuser. Issue #749
2023-05-04T11:32:36+00:00

insaner
insaner@users.noreply.github.com

2023-01-26T02:35:07+00:00

730ed9dc454e97f569df8a92ac065a1afcc05baa












Test if XResQueryClientIds() is available before using it.
2023-01-14T20:32:41+00:00

Joakim Tjernlund
joakim.tjernlund@infinera.com

2022-12-29T13:51:57+00:00

03dff122fda80db045f3c82e6cc272c3f8c5f7e4

Needed for X2Go as it does not have XRES 1.2 extension.





Needed for X2Go as it does not have XRES 1.2 extension.







Test Xres 1.2 is present
2023-01-14T20:32:33+00:00

Joakim Tjernlund
joakim.tjernlund@infinera.com

2022-12-19T15:59:06+00:00

2c0d3843a9e77f849f5f02a8b0ca9253a467e13e

Before using any Xres extension one must call XResQueryExtension()
Also make sure Xres 1.2 is available as marco need XResQueryClientIds()





Before using any Xres extension one must call XResQueryExtension()
Also make sure Xres 1.2 is available as marco need XResQueryClientIds()







test return value from XResQueryClientIds()
2023-01-14T20:31:49+00:00

Joakim Tjernlund
joakim.tjernlund@infinera.com

2022-12-19T15:58:10+00:00

318621e5c8ed760f97c180c34990d1560ac7fc05












replace _NET_WM_PID with XResGetClientPid (#741)
2022-11-12T16:27:19+00:00

Jan Novotný
59669705+CuBeRJAN@users.noreply.github.com

2022-11-07T14:32:33+00:00

d3add65f6960dd3c95aaa2fe63cc8c563747695d

window-props: use XResQueryClientIds to get pid

_NET_WM_PID is unreliable! It can be faked or pid might be from
different namespace. Ignore _NET_WM_PID and use XResQueryClientIds
to get pid.

https://gitlab.gnome.org/GNOME/metacity/-/commit/bcbe966511362a8eb8c8c64035ab160086c931f8




window-props: use XResQueryClientIds to get pid

_NET_WM_PID is unreliable! It can be faked or pid might be from
different namespace. Ignore _NET_WM_PID and use XResQueryClientIds
to get pid.

https://gitlab.gnome.org/GNOME/metacity/-/commit/bcbe966511362a8eb8c8c64035ab160086c931f8






Always bring into foreground the previous window after closing one
2022-11-12T16:26:58+00:00

Balazs Endresz
balazs.endresz@gmail.com

2022-11-01T17:15:22+00:00

85ce3f72a00c620aa7631b33eba1e8f4fc8b131f

When opening and then closing certain applications
the focus was correctly regained by the previous window
but it wasn't brought into the foreground.

To fix this we call meta_workspace_focus_default_window() for both NotifyDetailNone and NotifyPointerRoot.

These two are always mentioned together in the X docs:
https://tronche.com/gui/x/xlib/events/input-focus/normal-and-grabbed.html

Some programs will have NotifyDetailNone when closed, while others end up with NotifyPointerRoot.





When opening and then closing certain applications
the focus was correctly regained by the previous window
but it wasn't brought into the foreground.

To fix this we call meta_workspace_focus_default_window() for both NotifyDetailNone and NotifyPointerRoot.

These two are always mentioned together in the X docs:
https://tronche.com/gui/x/xlib/events/input-focus/normal-and-grabbed.html

Some programs will have NotifyDetailNone when closed, while others end up with NotifyPointerRoot.