search

phenax / bsp-layout

Manage layouts in bspwm (tall and wide)
MIT License
373 stars 30 forks source link

`--master-size` does not include display padding in available screen space calculation #78

Open marcxjo opened 2 months ago

marcxjo commented 2 months ago

What did you expect to happen?

When I use bsp-layout to set a tiling layout and using the --master-size flag, I expect the size of the master window to be a percentage of screen space available after calculating padding.

What actually happened?

When I use bsp-layout to set a tiling layout and using the --master-size flag with a given value X, while varying the display padding of that workspace (globally or locally), the size of the master window is constant (and appears to be calculated in terms of the total display size minus window_gap).

Describe your attempts to resolve the issue

Haven't tried yet, but all that should be needed is to include the most specific defined value from global/monitor/workspace padding settings in the calculation of available monitor space.

I'll put some time into this soon - I'm mainly raising the issue for confirmation that the change I'm proposing here is desired. Assuming that maybe other folks just don't pad their screens as drastically as I do, so a need for to adjust for it has just never surfaced, but that's just an assumption.

Steps to reproduce

These commands were run on a 3440x1440 monitor with 4 terminal windows open.

$ bspc config left_padding 488
$ bspc config right_padding 1288
$ bsp-layout set tall I -- --master-size 0.3
$ xdotool getactivewindow getwindowgeometry
Window 25165827
  Position: 520,76 (screen: 0)
  Geometry: 998x1330
$ bspc config left_padding 0
$ bspc config right_padding 0
$ bsp-layout set tall I -- --master-size 0.3
$ xdotool getactivewindow getwindowgeometry
Window 25165827
  Position: 32,76 (screen: 0)
  Geometry: 998x1330

Note that the master window is shifted to the left but not resized.

System Information

Installed bsp-layout to /usr using a modified AUR PKGBUILD to use latest master commit (actually the tip of #77, but the change in that branch shouldn't be consequential to this behavior - I can also reproduce in latest master).

OS arch:

$ uname -osrm
Linux 6.9.4-arch1-1 x86_64 GNU/Linux