Re: Fix bad shift when squeezing with 3D borders disabled

Hi, just to not forgot... :)

https://github.com/maxatome/ctwm-mirror/commit/ee70936830720992ba63cd29ef3220331c663e95

++

Max.

On 12/07/2020 15:07, Maxime Soulé wrote:
> Hi,
>
> On 12/07/2020 00:31, Matthew D. Fuller wrote:
>> On Thu, Jul 09, 2020 at 06:33:05PM +0200 I heard the voice of
>> Maxime Soulé, and lo! it spake thus:
>>> [snip]
>>> It is weird (but probably historic?) that frame_bw and frame_bw3D
>>> fields have the same meaning for the user (the border width, but one
>>> for flat design and the other for 3D), but are not used equally in
>>> the code.
>>
>> This is trickier than it seems like it should be because of how the
>> borders work.  The 2d border is an X border (setup in the
>> XCreateWindow() for the frame, add_window.c:1524), which is on the
>> outside of our frame window.  The 3d border is a drawing we do
>> _inside_ the frame.  So, with 2d borders, the left side of the
>> internal window is at X coordinate 0 relative to the frame, whereas
>> with 3d it's a ->frame_bw3D.
>>
>> See also the comment in win_decorations.c:1527.  That's why we're
>> often doing things like -frame_bw (because it's "outside" of our
>> stuff), but +frame_bw3D (because it's "inside").
>
> OK, understood, thanks for the explanation.
>
> So I think there is a related problem in functions_identify.c:112
>
> XGetGeometry() is not done on the frame, so bw is always 0 (even in 
> flat design).
>
> We should have something like:
>
>         XGetGeometry(dpy, t->w, &JunkRoot, &JunkX, &JunkY,
>                      &wwidth, &wheight, &JunkBW, &depth);
>                 bw = t->frame_bw;
>
> Regards,
>
> Max.