Set _NET_FRAME_EXTENTS
according to the actual decoration size
#5944
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Inspired by #5384, but instead of just using the border width, this PR reports the actual frame extents for the window, which may also include the title bar (for floating windows and tiled windows in plain split containers, but not for tiled windows in stacked/tabbed containers).
The existing
con_border_style_rect()
function should already handle all configuration options which can affect the decoration sizes (if it does not, that would also show up in other places); its result just needs to be converted into the format used by the_NET_FRAME_EXTENTS
property.This PR fixes #4292 probably in the best way possible (the reported
_NET_FRAME_EXTENTS
values should always match the actual sizes of window frame elements which are actually drawn into the X11 frame window into which the client window is reparented). The only really problematic case is with the stacked/tabbed containers, for which the title bar is actually drawn into a completely separate window, therefore the title bar size cannot be reported in_NET_FRAME_EXTENTS
(actually I tried to calculate the size of those decorations and add it to the top decoration size, but that did not change the behavior ofpicom
).Large screenshots here (3840×2160)
Example of configuration with
hide_edge_borders smart
— a single window does not have borders, so only the top frame size is non-zero:but multiple windows have borders:
Changing border width works too (although with
border normal 8
you can see that the top border overlaps the title text, because on the i3 side that border does not really exists, andpicom
just draws it over; also the pixel sizes reported byxprop
andxwininfo
are not identical to what is specified in i3, because I use 168 dpi on this system, therefore 4 px in the i3 config = 7 dpx):Handling of tabbed containers is less perfect though. Here is a single tabbed container with
hide_edge_borders smart
, so it does not really have a border — note that all frame extents are zero, and the titlebar is rounded separately (although it could easily be excluded from rounding, that does not really help much):Once the border actually appears, you may notice that the top part of the
picom
border actually gets drawn over the top part of the window, partially obscuring the top line in this terminal (picom
does not mind that the top frame size is reported as 0):Some examples of floating windows (no major problems there):
Options like
hide_edge_borders both
work too when gaps are removed (although the resulting behavior withpicom
is probably not very useful — the rounded border gets drawn only if all of the left, bottom and right borders are present):The same with
border pixel 8
(note that windows with only the top border hidden still get the rounded border treatment bypicom
, but the border overlaps the top part of the window):