paperwm / PaperWM

Tiled scrollable window management for Gnome Shell

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Not sure if bug - inconsistency between bottom margin and top margin calculation

jonseppanen opened this issue · comments

Describe the bug
In the paperWM settings there are 2 fields - bottom margin which adds a bottom margin, and top margin which adds a top margin.

This works fine - however, the setting for window gaps, which in a horizontal stacking window manager one would assume means just that - gaps between windows, also adds half its margin to the top as well, but not the bottom.

I think this is inconsistent and perhaps wrong, especially if someone wants to use a floating status bar (like I am) and wants a consistent gap between the top and bottom of the bar - this results in too much space between the tops of windows and the status bar.

To Reproduce
Steps to reproduce the behavior:

  1. Go to settings
  2. Go to top gap
  3. Set to 0
  4. Go to gap between windows
  5. set to any large number
  6. There now is a gap at the top of the window, when perhaps there should not be

Expected behavior
I would expect:

  • Top margin to only add top margin (it does not)
  • Bottom to only add bottom margin (it does)
  • Window gap to only add gap horizontally between windows (it does not)
  • Horizontal gap to only add gaps to the sides of a monitor

Alternatively

  • Horizontal margin only adds space between windows
  • Window gap adds margin on all sides of a window
  • Top margin to only add top margin
  • Bottom to only add bottom margin

Screenshots
N/A

System information:
Not necessary

Additional context
I have locally made a 1.5 line code change that fixes the issue in what I believe is the original intention of the settings. It took about 5 seconds and a relogin,

Line 112 - 116 in tiling.js

  let setVerticalMargin = () => {
      let vMargin = gsettings.get_int('vertical-margin');
      // let gap = gsettings.get_int('window-gap');
      Settings.prefs.vertical_margin = vMargin;
  };

Thanks @jonseppanen,

I believe the original intent was to keep the selection element (the coloured border around the selected window in check). However, by definition the original setVerticalMargin is dependent on the window-gap, but so is the selection element size (which causes the funny issues when window-gap is larger than the vertical-margin.... which isn't ideal.

The changes you did (alone) introduces another issue, e.g. do the same and made the window gap very large and the selection element becomes much too large and the element then covers the topbar etc.:

image

I think you're changes, along with changes to the the selection element size would make this much better (and simpler).

Actually, having an option to set the selection element size (e.g. the "thickness" of the border for the selected/focused window) would remove confusion and make this much simpler. It would be much better than the current approach of having these things dependent on each other.

@jonseppanen, could you please checkout branch improve-margin-settings and test it out?

git checkout improve-margin-settings
./install.sh

then logout/login.

Thanks!

Thanks for jumping on this so quick, I will pull down and check it out today!

Just checked now, its absolutely perfect. Thanks!

Released.