_NET_FRAME_EXTENTS includes border_width

[psychon]

Originally this was reported at awesomeWM/awesome#425

Hi,

I'd suggest reading the report at the above bug report first. What follows is mostly me making assumptions about compton's internals without having tested anything.

It seems to be that _NET_FRAME_EXTENTS should already include any border width that is applied to the frame window that a window manager adds, therefor (untested, I'm just looking at the code):

• win_get_region_noframe shouldn't add border_width to the frame extents (if frame extents are set; I guess without _NET_FRAME_EXTENTS, border_width is the best approximation of the frame extents that you can get)
• win_paint_win should'nt add border_width to the frame extents either. Also, this code contains a comment which might need to be re-evaluated since at least it might be possible that Openbox also uses a border:

The following complicated logic is required because some broken window managers (I'm talking about you, Openbox!) that makes top_width + bottom_width > height in some cases.

• Perhaps get_frame_extents should fall back to the border width if the property doesn't exist? (In which case this function would also need to be called when the border width changes).

Cheers,
Uli

[richardgv]

Thanks for the detailed analysis!

I changed the method to calculate frame extents to use the larger one in _NET_FRAME_EXTENTS and the X window border width in c156abb (richardgv-dev branch). It works for fluxbox-1.3.7, which originally has the problem as well. Did not reproduce the bug with awesome since I am using the stable version 3.5.6.

I did not choose to entirely rely on _NET_FRAME_EXTENTS when it is present, to make the logic simpler and (hopefully) take care of some cases when it is wrong and smaller than the X window border width.

I am not feeling very certain about whether there are WMs that does not include X window border width in _NET_FRAME_EXTENTS, though. So far I have only noticed Fluxbox and awesome including it in _NET_FRAME_EXTENTS.

Also, this code contains a comment which might need to be re-evaluated since at least it might be possible that Openbox also uses a border:

The following complicated logic is required because some broken window managers (I'm talking about you, Openbox!) that makes top_width + bottom_width > height in some cases.

I was actually talking about the bug that Openbox does not change _NET_FRAME_EXTENTS when a window is rolled up and the border on bottom is removed. See the bullet point 3 in #17 (comment) . Nothing to do with X window border width.

[richardgv]

I merged the change to master branch as BenoitZugmeyer confirmed it works.