xmonad/xmonad-contrib

XMonad.Layout.ResizableThreeColumns : possible bug

thealio opened this issue · 7 comments

I'm writing to you , because I encountered a possible bug using this layout. Following, here are the details and the steps for reproduce it


Distro: Arco Linux (it uses the Arch Linux repos)


Xmonad sets:
(From https://xmonad.github.io/xmonad-docs/xmonad-contrib-0.17.0.9/XMonad-Layout-ResizableThreeColumns.html)
#339

import XMonad.Layout.ResizableThreeColumns

myLayout = ResizableThreeColMid 1 (3/100) (1/2) [] ||| etc.. main = xmonad def { layoutHook = myLayout }

, ((modm, xK_a), sendMessage MirrorShrink)
, ((modm, xK_z), sendMessage MirrorExpand)


Steps to reproduce the bug

  1. Layout : ResizableThreeColMid
  2. Open at least 5 windows
  3. Focus the bottom right slave window
  4. Try MirrorShrink or MirrorExpand

Bug: MirrorShrink or MirrorExpand don't work with the focus on the bottom right slave window

What I expected : the bottom right slave window shirnks or expands as the other slaves (other slaves work as expected)


I'd like to know if other users encounter the same issue/ behavior on their configs
Thank you & best regards

Thanks, this should be bandaid-fixed by f7e9c0c. To quote:

[Fix the problem] ...by introducing yet another special case. Unsurprisingly, this is just a bandaid—the logic in this module is just wrong. It purposefully (not introduced with this change) computes the wrong positions for certain extreme points such that splitVertically (which simply goes down the list of stack windows in order) still works.

What we should do instead is to either

  • keep track of windows that want to change their size and compute a rectangle for them first, or

  • immediately when handling the resize message, compute all of the new sizes immediately (instead of only for the window getting resized).

The latter would force us to keep track of the size of the current stack we operate in, but since 'handleMessage' lives in X this should not pose a big problem. I reckon this is the better approach.

Thank you forma working on it!
Currently, the problem is not fixed in Arch (I use Arco Linux)

Are you using the standard package, or xmonad-git from AUR? You may need the latter until Arch updates its packages.

Standard, I suppose, I'll check it later
Thank you for your hard work on xmonad!

Are you using the standard package, or xmonad-git from AUR? You may need the latter until Arch updates its packages.

Hi
on Arch the bug is still present
It's a lot of time
Can someone confirm this on Arch?

The xmonad-git AUR package was last updated on 2022-01-11 11:16 (UTC), while the fix was commited in December. I would advise you to check out install and install XMonad with stack

The xmonad-git AUR package was last updated on 2022-01-11 11:16 (UTC), while the fix was commited in December. I would advise you to check out install and install XMonad with stack

Thank you so much
Iìll wait until official Arch repos will include this commit (it's not a serious issue)