Skip to content
This repository has been archived by the owner on Nov 7, 2022. It is now read-only.

Outer gaps cause weird tiling #22

Closed
Airblader opened this issue Jan 1, 2015 · 16 comments · Fixed by i3/i3#5252
Closed

Outer gaps cause weird tiling #22

Airblader opened this issue Jan 1, 2015 · 16 comments · Fixed by i3/i3#5252

Comments

@Airblader
Copy link
Owner

Effect seems to be stronger the bigger the outer gaps are. Doesn't seem to happen when outer gaps aren't used.

@Airblader
Copy link
Owner Author

This is actually probably just due to the way the gaps patch works. I'll still try to take a look at it sometime.

@Airblader Airblader added enhancement and removed bug labels Jan 2, 2015
@Airblader
Copy link
Owner Author

I will shelve this for now as it is pretty much "works as intended". If it comes up again, this can be reopened.

@cameronleger
Copy link
Contributor

I just want to note on this issue that there's possibly a fix for it in this commit: op8867555/i3-gaps@26bdec7

I hadn't noticed this, I guess because I don't usually tile in 3+ columns, but I just confirmed it still happens.

@op8867555, do you have the time to update your branch for a PR if this is an easy fix?

@op8867555
Copy link
Contributor

@cameronleger I think the patch is simply enough to update / rebase. Should I just update it (without feature-54) to current gaps-next and send a PR?

@cameronleger
Copy link
Contributor

I'll let the owner decide what to do, but assuming #210 is merged then the math will have to be updated, so perhaps merging onto that branch will be less work than doing it twice. Those changes are also straightforward.

@Airblader
Copy link
Owner Author

From the top of my head I see nothing wrong with the idea of that patch, though it might be worth testing it for a while.

I'd also say let's test and merge #210 first and then revisit this.

@op8867555
Copy link
Contributor

It's sounds good to me, I will give #210 a try first.

@cameronleger
Copy link
Contributor

@Airblader, should we revisit this? Personally, it's not a high priority, but I can see it being raised again given the new gap options.

It's visible with three vertical columns and non-zero side gaps. I rarely have three columns, and if I do I remove the side gaps for the extra space, which is why I don't consider it a huge issue.

Here's an image previously posted on #54 that describes the issue:
Tiling Issue

@Airblader
Copy link
Owner Author

Yes, I'd definitely not be opposed to fixing this. :)

@Airblader Airblader reopened this Nov 5, 2018
cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 9, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, the containers stop considering the edges, and instead the workspace as a whole is inset before any containers
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 10, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, the containers stop considering the edges, and instead the workspace as a whole is inset before any containers
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 10, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, the containers stop considering the edges, and instead the workspace as a whole is inset before any containers
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 10, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, the containers stop considering the edges, and instead the workspace as a whole is inset before any containers
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 10, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, the containers stop considering the edges, and instead the workspace as a whole is inset before any containers
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 10, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, the containers stop considering the edges, and instead the workspace as a whole is inset before any containers
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 10, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, the containers stop considering the edges, and instead the workspace as a whole is inset before any containers
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 10, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, the containers stop considering the edges, and instead the workspace as a whole is inset before any containers
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 10, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, the containers stop considering the edges, and instead the workspace as a whole is inset before any containers
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 10, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, containers always inset by the inner gap settings, and the workspace is now inset by the outer gap settings
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
Previous combinations of outer/inner gap settings still produce the same result, albeit with fixed outer-most sizes
cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 10, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, containers always inset by the inner gap settings, and the workspace is now inset by the outer gap settings
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
Previous combinations of outer/inner gap settings still produce the same result, albeit with fixed outer-most sizes
@cameronleger
Copy link
Contributor

OK, I believe I've fixed this as my test results show perfectly tiling grids that respond as I'd expect them to with different combinations of outer/inner gaps. I just opened #253 for this.

Put simply, containers will only consider inner gap settings, and the workspace is now inset by the outer gap settings.

cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 10, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, containers always inset by the inner gap settings, and the workspace is now inset by the outer gap settings
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
Previous combinations of outer/inner gap settings still produce the same result, albeit with fixed outer-most sizes
cameronleger added a commit to cameronleger/i3 that referenced this issue Nov 10, 2018
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, containers always inset by the inner gap settings, and the workspace is now inset by the outer gap settings
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
Previous combinations of outer/inner gap settings still produce the same result, albeit with fixed outer-most sizes
cameronleger added a commit to cameronleger/i3 that referenced this issue Apr 19, 2019
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, containers always inset by the inner gap settings, and the workspace is now inset by the outer gap settings
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
Previous combinations of outer/inner gap settings still produce the same result, albeit with fixed outer-most sizes
@seletskiy
Copy link

This issue is particularly noticeable on 4K screen.

When I try to make some workspace smaller than 4K and put in the center using outer gaps, after splitting it into three columns one window which is closest to the outer gap gets size < 0 (which, I think, cause uint overflow) and window gets completely corrupted because of that.

cameronleger added a commit to cameronleger/i3 that referenced this issue Jul 4, 2019
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, containers always inset by the inner gap settings, and the workspace is now inset by the outer gap settings
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
Previous combinations of outer/inner gap settings still produce the same result, albeit with fixed outer-most sizes
@cameronleger
Copy link
Contributor

@seletskiy, are you speaking about the released i3-gaps or the branch I have that works-around this issue? I have a few changes that I try to keep up-to-date and applied on-top of this repo, and in my experience it resolves this issue and I haven't seen any new issues.

gaps-next...cameronleger:fix-22

@seletskiy
Copy link

@cameronleger I was talking about released i3-gaps. Just tested your branch (fix-22) and it works great. Marvellous work 💯.

Hope it will be merged into upstream.

@Airblader
Copy link
Owner Author

While I recognize that is (still) a valid issue, I will close it in lieu of i3/i3#3724

cameronleger added a commit to cameronleger/i3 that referenced this issue Jan 9, 2021
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, containers always inset by the inner gap settings, and the workspace is now inset by the outer gap settings
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
Previous combinations of outer/inner gap settings still produce the same result, albeit with fixed outer-most sizes
cameronleger added a commit to cameronleger/i3 that referenced this issue Mar 14, 2021
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, containers always inset by the inner gap settings, and the workspace is now inset by the outer gap settings
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
Previous combinations of outer/inner gap settings still produce the same result, albeit with fixed outer-most sizes
@Airblader
Copy link
Owner Author

@cameronleger I somehow missed your patch all this time. Thank you so much for sharing it here. Let's see if we can upstream this in our effort to merge the i3-gaps and i3 projects.

cameronleger added a commit to cameronleger/i3 that referenced this issue Oct 30, 2022
Currently, containers only consider their neighbors and screen edges
If >2 containers are in a line, the outer containers adjust from outer gaps, but the middle containers know nothing of this and only consider the inner gaps
When the outer gaps differ substantially from the inner gaps, the outer containers are smaller as only they adjust for the larger outer gaps

With this change, containers always inset by the inner gap settings, and the workspace is now inset by the outer gap settings
The result is that many tiled containers have the same size, and the gaps overall work as the user might expect them to
Previous combinations of outer/inner gap settings still produce the same result, albeit with fixed outer-most sizes
@cameronleger
Copy link
Contributor

That is quite alright; I believe another issue or pull request was where other related conversations occurred, and you had mentioned wanting additional tests to be sure about the changes since it was a significant change. I've been running that branch for years without issues. I'll rebase and rebuild for now!

stapelberg pushed a commit to stapelberg/i3 that referenced this issue Nov 6, 2022
Currently, containers only consider their neighbors and screen edges.

If >2 containers are in a line, the outer containers adjust from outer gaps, but
the middle containers know nothing of this and only consider the inner gaps.

When the outer gaps differ substantially from the inner gaps, the left-most and
right-most containers are smaller as only they adjust for the larger outer gaps.

This commit changes the rendering: containers are now always inset by their
inner gap settings, and workspace containers is now inset by the outer gap
settings.

The result is that many tiled containers have the same size, and the gaps
overall work as the user might expect them to previous combinations of
outer/inner gap settings still produce the same result, albeit with fixed
outer-most sizes.

fixes Airblader/i3#22

related to i3#3724
stapelberg pushed a commit to stapelberg/i3 that referenced this issue Nov 6, 2022
Currently, containers only consider their neighbors and screen edges.

If >2 containers are in a line, the outer containers adjust from outer gaps, but
the middle containers know nothing of this and only consider the inner gaps.

When the outer gaps differ substantially from the inner gaps, the left-most and
right-most containers are smaller as only they adjust for the larger outer gaps.

This commit changes the rendering: containers are now always inset by their
inner gap settings, and workspace containers is now inset by the outer gap
settings.

The result is that many tiled containers have the same size, and the gaps
overall work as the user might expect them to previous combinations of
outer/inner gap settings still produce the same result, albeit with fixed
outer-most sizes.

fixes Airblader/i3#22

related to i3#3724
stapelberg added a commit to i3/i3 that referenced this issue Nov 6, 2022
…5252)

Currently, containers only consider their neighbors and screen edges.

If >2 containers are in a line, the outer containers adjust from outer gaps, but
the middle containers know nothing of this and only consider the inner gaps.

When the outer gaps differ substantially from the inner gaps, the left-most and
right-most containers are smaller as only they adjust for the larger outer gaps.

This commit changes the rendering: containers are now always inset by their
inner gap settings, and workspace containers is now inset by the outer gap
settings.

The result is that many tiled containers have the same size, and the gaps
overall work as the user might expect them to previous combinations of
outer/inner gap settings still produce the same result, albeit with fixed
outer-most sizes.

fixes Airblader/i3#22

related to #3724

Co-authored-by: Cameron Leger <contact@cameronleger.com>
desmana pushed a commit to desmana/i3 that referenced this issue Feb 27, 2023
…3#5252)

Currently, containers only consider their neighbors and screen edges.

If >2 containers are in a line, the outer containers adjust from outer gaps, but
the middle containers know nothing of this and only consider the inner gaps.

When the outer gaps differ substantially from the inner gaps, the left-most and
right-most containers are smaller as only they adjust for the larger outer gaps.

This commit changes the rendering: containers are now always inset by their
inner gap settings, and workspace containers is now inset by the outer gap
settings.

The result is that many tiled containers have the same size, and the gaps
overall work as the user might expect them to previous combinations of
outer/inner gap settings still produce the same result, albeit with fixed
outer-most sizes.

fixes Airblader/i3#22

related to i3#3724

Co-authored-by: Cameron Leger <contact@cameronleger.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants