fix: clamp tiling windows with their working rects

[mzhu-zx]

If a window is on the edge of the monitor and has a large shadow border, the computed rectangle can exceed it ancestor monitor's the working rectangle, which places it on a neighbor monitor instead. The DWM will render the window either too long or too wide in a dual monitor setting where two monitors of different sizes are not perfectly aligned.

To fix this, a new function clamp_strictly is added to restrict all computed rectangles in tiling mode to the working rectangle of the ancestor monitor. The existing clamp function cannot guarantee this. Consider rectangles in (x, y, w, h): (0, 0, 3, 3) and (1, 1, 3, 3) where the latter is the outer. The intersection of those 2 rectangles needs to have width and height 2 instead of 3.

[lars-berger]

@mzhu-zx Thank you for the PR! 🙌

I just tried your fix branch - it's clamping successfully to the bounds of the monitor. Added a fix just now so that it only affects tiling windows (e.g. to allow floating windows in between the edges of two monitors).

However, I'm having trouble finding an example window to test this out with. Would you mind showing a screenshot of a window with excessive window borders before/after the fix?

A problem I'm noticing with the fix is that it causes the windows to not take up the proper width/height with 0px outer gaps:

Also, not sure if this affects your use case but there's an adjust-borders command available for tweaking window-specific borders.

[mzhu-zx]

Hi @lars-berger , thanks for the review.

I didn't notice the gap. After a couple of more attempts, I think this is related to #1111 as well. When I set both of my monitors to have the same scaling, the problems is gone. The problem with the zero-width outer gap is that it seems to be implemented by making the window bigger to compensate for the border width. When placed at the edge of a screen, it will inevitably span to the next screen. This is where scaling can screw things up.

I'm reproducing this using Emacs on Windows. I cannot preclude the case that it's because Emacs has some internal window handling that's miscalculating the rectangle. Here's a screenshot:

(Note that the black edges are fine, but there's an overflow of the Emacs window on the left that goes beyond the bar on the top. Similarly the window on the right screen overflows the bottom edge as well.)

The adjust-boarders command works for me, although it seems that you cannot apply this command to windows by name. I added an option to adjust by class name, e.g.,

cargo r -- command adjust-borders --left -8 --right -8 --class-name Emacs

At this point, the clamping adjusted_rect indeed doesn't appear to be a perfect solution. I'm more interested in investing in the adjust-borders approach. I cannot recall if there is another GUI program other than Emacs suffering from a similar issue, as most modern programs, probably DPI-aware ones, don't need to be clamped.