Enhancement: Add ability to resize outer gap horizontaly or vertically

[rickisen]

Hi, first time adding a feature request on github... accidantely pushed enter too early.

Just wanted to mention that it would be cool if there was a way to specify the vertical outer gap seperatly to the horizontal. It's possible in xmonad, and I find it quite usefull for having my two conky windows visible in one layout.

[Airblader]

Going off the tiny description you put into the title rather than the actual description: no. The gaps are already complex enough.

[rickisen]

Sorry accidentaly submitted the issue before I got to the description. I edited it now.

[Airblader]

I think your usecase is better adressed by i3/i3#1129

[Airblader]

However, I do think I want to think about this some more. I'll reopen it for now.

[rickisen]

Oh thanks for reconsidering it and sorry for beeing so clumpsy about the whole thing.

The veritcal bar solution sounds interesting, but I guess that would mean that conky would allways be vissible, except in fullscreen mode.

Personally I use it in xmonad more like a temporary layout, and mostly when I have one window open that doesn't gain much from using the full width of my display, so often while browsing the web and maybe downloading something or rendering/compiling in the background. And then I switch to a layout whith no outer border when I open a new window.

[Airblader]

I've implemented this as a proof of concept on feature-54. I'm not yet sure I really want to merge this.

[rickisen]

Cool! You just made my day.
I built this branch without problems and I'm now running it on my main machine. And so far it works great.
I ended up binding "gaps outer current horizontal set 270" and "set 0" to two keycomobos, so I'll be switchng like crazy now :). I'll inform you if I find any hickups, but so far so good.

Btw, I like the ability to specify top,bottom,left,right values. Should be handy for people with only one conky-window, or with a vertical panel. Kinda reminds me of css margins.

So I, for one, hope you'll end up merging it.

[Airblader]

The problem I have is something not actually related to this change itself: with somewhat "extreme" gaps, the tiling geometry can get pretty weird. Try setting your gaps like that and opening a few windows in a grid (see #22)

[Airblader]

By the way, sorry there is no progress here right now. I'm really busy at the moment, but I'll get back to this.

Have you been using the proof of concept? If so, it'd be great to hear if your experience with it changed.

[rickisen]

Yes im activly using it on both my laptop and desktop. And it works as expected. No weird crashes or anything.

I havent gotten very creative with it though. It's just configured to a keycombo to add horizontal gaps, and one to remove them. And on workspace 1 they are on by default. So I use it all the time.

I haven't been able to figure out a way to automatically remove the horizontal gaps if there are more than two windows in a workspace though. But I can live with that.

[DanielVoogsgerd]

I love what you did with conky on the sides there! I'd like to see this as well.
I thought I might as well mention it while the issue is still open (and I suspect you haven't decided whether you want to merge it or not).

[rickisen]

Yeah, Me too.

I'm still running "feature-54", and it works really smooth. Daniel, you can check out my dotfile-repo if you want some conky inspiration.

[Airblader]

Sorry I've been letting this hang, guys. I think I'm ready to give this a try, but I'll need to adapt it a bit (just to make it prettier) and rebase it.

[Airblader]

I should've added: I am a bit preoccupied with a big patch for i3 that I'm working on, so please be a bit more patient. But I will merge it back.

[Tonus1]

Take your time, that's great news !

[mmetak]

Hi @Airblader. Any news on this feature?

[Airblader]

@mmetak To be honest I completely forgot about it. My bad. The patch still needs to be cleaned up a lot. I'm pretty busy at work at the moment and will work on it once I find the time. Of course pull requests implementing this cleanly are welcome as well.

[maestrogerardo]

Hi, I'm also looking forward to such feature as I've got pretty much the same use case (I want conky not being covered by windows while the windows themselves use as much [vertical] space possible).

@rickisen: Nice setup! @Airblader: Thanks for your work!

[squigglezworth]

Is there any chance we could get this feature fixed and merged into i3-gaps? Unfortunately we can't just merge the old feature-54 branch without conflicts anymore.

[Airblader]

I'm just too busy to work on this, but anybody can turn this into a properly written pull request that I'll happily review. But please note that I don't just mean "rebase it to the current HEAD", but actually design the feature properly. There's work left to do.

[EgonSpengler]

I'm likewise interested in the future of this feature, so this holiday weekend I'll also look into getting this running and/or improved for use.

[madnight]

hi i use polybar and define the following settings:

offset-x = 20
offset-y = 12
override-redirect = true
wm-restack = i3

so that my bar ist floating like this:

The problem is that i3-gaps does not respect the bar position ... therefore i would need a way to define more upper gap than lower gap

I'm also use conky so i have additionally the same problem like the issue starter, with the conky spacing.

[snippins]

Hi all,
I try to apply the draft commit manually and got it working for 4.13 version. However, restarting by the "restart" command cause i3 to crash. Ofcourse we can manually kill and rerun i3 in a script to workaround this problem.

[madnight]

@snippins i think the restart problem of feature-54 can be debugged ... however we need to convince Airblader that this feature does make sense

13 changed files with 142 additions and 42 deletions is not overly complex for this feature and a rebase shouldn't be to time consuming (i guess)

[Airblader]

As I said, I'm OK with the change but I don't have time to do it myself at the moment. A serious pull request that fulfills what I wrote above (read: not just a rebase) is welcome.

[reedrw]

Any update on this? I'm still very interested.

[madnight]

@rmw5601 i can recommend bspwm, should have everything you need

[cameronleger]

I too have wondered about this feature for a while, so I figured it's time to do something about it.

First, I have a branch that simply reapplies the feature-54 branch's changes onto the latest version. I did this to get familiar with what was changed and to make sure it worked years later. I haven't done much on this one other than that, and it works!

Also, I have a different branch that takes a slightly different approach to this request, one that I hope @Airblader would prefer.

From a user's perspective, it simply adds horizontal and vertical gaps into the existing syntax. This might be controversial because the syntax is inner|outer|horizontal|vertical and h/v could fit under the outer category. However, I think that the relatively minor code and syntax changes outweigh the imperfect categorization. I prefer the simplicity of mirrored side margins instead of a margin for each side, but I don't have any use-cases for the separate controls so if you do please share! For trying these out - on Arch at least - it's very easy to swap the git URL in the PKGBUILD to either branch and build from there.

From a technical perspective, it adds two scopes, horizontal and vertical, that largely fit in where inner and outer would, and they are used exactly like inner/outer as opposed to replacing the simple outer scope with another structure. Minor refactoring is done for the additional code and some existing code (passing through scopes instead of a bool for inner/outer). The hackyness of the original branch (using single struct variables to pass values when both a single value and struct are expected inputs) is resolved.

I'm not that familiar with the codebase or operations, so I'm not sure what else to do to satisfy the owner. I'm willing to put in more work if a little guidance is given. In my opinion, this is such a simple modification and can easily be left alone, so it's worth including with this fork. Some further refactoring might be warranted for DRY, and I don't know how to run/update the tests.

As always, I appreciate your time and effort.

[Airblader]

Thanks for the work! From your description it sounds good to me. Can you send a PR so we can go over the changes? It's easier in the UI for pull requests. :-)

[Airblader]

On a side note, I won't require this here since we don't have any gaps-related tests at all so far, but if you (or anyone) wanted to work on adding some tests, that'd be of great help for maintaining i3-gaps in the future. It's probably pretty easy to write test cases since we can just assert on the rect of the containers.

[Airblader]

The proposed PR looks great to me. Given the interest in this feature, I'd appreciate if someone was willing to run the PR (and test it a little) for a couple days to just have some additional feedback. Does anyone feel like doing so?

[op8867555]

I just tried @cameronleger's branch in Xephyr and found out the weird tiling problem (#22) still happens.

Sorry to hijack the thread, but I also have a local patch for this feature which based on feature-54 but took a different approach, I tried to inset the whole workspace container instead of each leaf and the tiling problem haven't happened so far. Hope this helps.

[Airblader]

@op8867555 That's cool that you have a patch for that. I'd really like to fix this, but I don't feel strongly about doing it here or in a separate PR afterwards since the issue is independent of this feature.

[op8867555]

Oh, I thought it need to be solved by "fulfills you wrote above". I think I misunderstood what you said 😅.

[op8867555]

As @A-Manning mentioned in #210, more fine-grained control like upper, lower, left, right might be a good option. A use case for that is, we will able to setup a single conky sidebar like this

or an unbalanced setup, e.g. 100px on left and 200px on right.

[zemmsoares]

Hey! I'm using i3-gaps and this would be awesome to make top gap for my polybar since i'm on a small 12" laptop.. also new to github will this be merged to the master branch? or any way i could use it?

[Airblader]

@zemmsoares Once merged, it will be on the branch gaps-next for the foreseeable future. You can use it by checking out the branch of the pull request and compiling that yourself.

@op8867555 Well, alright. I'm open to that. But we should discuss the syntax.

[op8867555]

@Airblader I would propose the following two syntax,

• follow Adding 'horizontal' and 'vertical' to the types of gaps #210

  gaps [inner|outer|left|right|top|bottom|horizontal|vertical] [current|all] 
  [plus|minus|set]
  

• follow feature-54 (I know the second outer is confusing, but I can't come up with a better word)

  gaps inner [current|all] [plus|minus|set]
  gaps outer [current|all] [plus|minus|set]
  gaps outer [top|left|bottom|right|horizontal|vertical] [current|all] [plus|minus|set]
  

In both case horizontal|vertical will be a syntax sugar for top|left|bottom|right where LR/TD have same values.

My question about it is, do we want separated outer/HV gaps or a unified one?

[Airblader]

I'd follow the #210 proposal, I liked that. I wouldn't split outer and H/V further – L, R, T, B, H, V are just finer controls of the same thing: outer gaps.

[cameronleger]

Yes, it would be reworked such that O adjusts L/R/T/B, H adjusts L/R, and V adjusts T/B. I can look into that this weekend, and I'll also check the weird outer tiling issue; although it's independent, this will likely increase awareness of it.

[cameronleger]

I just opened PR #211 which allows side-specific gaps in addition the the short-hand outer, horizontal, and vertical gaps. Considering that #210 simply added H/V options and this actually swaps outer gaps with T/R/B/L while still allowing higher-level modifications, it has the potential to break more things. I'd appreciate any testing on that branch to help us get to a proper solution here.

[Airblader]

#249 has finally been merged. Thanks everyone!

[Airblader]

I would of course appreciate if people tested it out just to make sure it's working correctly!