New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: more-aggressive [resize supergrow] function #3174

Open
moodboom opened this Issue Mar 13, 2018 · 11 comments

Comments

Projects
None yet
4 participants
@moodboom

moodboom commented Mar 13, 2018

Request for a [resize supergrow] function that will grow the target window even if other windows in the same container are already at mimimum size.

Currently, it seems that window growth is prevented once any other window in the container hits minimum size. Other windows in the container may still be large, and the container itself may only take up a small amount of total space. This is non-optimal on a very large screen with many containers. The user is forced into a multi-step process of navigating to those other windows and shrinking them. And it's even worse than that: as an "other" window is shrunk, the WRONG other windows will grow again. So the current optimal strategy is to go to the minimum-sized window and grow it, so it will shrink again when you go back to the original window and grow it. Correct me if I'm wrong, but this best-practice is very non-optimal.

It also seems that one container will grow to squash another container so that it is forced to shrink some of its windows below minimum size. This seems inconsistent.

It is expected that supergrowth would be done by stealing from other non-minimum windows within the container, and then from other adjacent containers, and then parent containers, until all other windows were at minimum size.

I would be interested in working on this if I haven't missed something and it sounds like a worthwhile idea to the main developers.

Output of i3 --moreversion 2>&- || i3 --version:

Binary i3 version:  4.14.1-175-g3f668baa (2017-11-05, branch "gaps-next") © 2009 Michael Stapelberg and contributors
Running i3 version: 4.14.1-175-g3f668baa (2017-11-05, branch "gaps-next") (pid 1562)
Loaded i3 config: /home/m/.i3/config (Last modified: Thu 15 Feb 2018 05:52:07 PM EST, 2213499 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3


@i3bot i3bot added the enhancement label Mar 13, 2018

@moodboom moodboom changed the title from Enhancement request: more-aggressive [size supergrow] function to Enhancement request: more-aggressive [resize supergrow] function Mar 13, 2018

@moodboom moodboom changed the title from Enhancement request: more-aggressive [resize supergrow] function to Enhancement: more-aggressive [resize supergrow] function Mar 13, 2018

@Airblader

This comment has been minimized.

Member

Airblader commented Mar 17, 2018

I'm not sure I understood all of the details, but it sounds like we could also just extend the current algorithm to keep growing the window by taking from other windows even if some window has already reached minimum size, right? So we wouldn't actually need a new command, which is something I'd like to avoid.

@moodboom

This comment has been minimized.

moodboom commented Mar 18, 2018

Agreed, we could change the existing command. I didn't know if changing functionality would be preferred over a new command that would leave existing functionality alone. It would likely be mapped to a key so it would be a matter of setting your preferred command and forgetting.

It may be that this impacts me more than others because I use one 52" monitor.

@moodboom

This comment has been minimized.

moodboom commented Mar 19, 2018

Here is another explanation via ASCII art...

     Attempt to widen this column
     v
__________________
|  |     |       |
|  |     |       |
|  |     |       |
|  |     |       |
|__|_____|_______|

 Once this column hits min width...
 |       ... this won't shrink further
 v            v
__________________
| |        |     |
| |        |     |
| |        |     |
| |        |     |
|_|________|_____|

@Airblader

This comment has been minimized.

Member

Airblader commented Mar 19, 2018

I think changing the existing behavior here is fine since we only make it more reasonable: what didn't work before will now work better. :-)

@Airblader

This comment has been minimized.

Member

Airblader commented Mar 19, 2018

I'll mark this as accepted, but we'll have to see whether the implementation will be reasonably simple.

@Airblader Airblader added accepted and removed discussion labels Mar 19, 2018

@moodboom

This comment has been minimized.

moodboom commented Mar 19, 2018

Awesome, thanks Airblader. I'll take a look at the code and try to find the simplest solution.

@moodboom

This comment has been minimized.

moodboom commented Mar 21, 2018

@Airblader here is a first pass that allows a growing window to pull from all of the other windows in its container. It is fairly simple. But I did have to add a minimum pct. 10% seemed to work well. But I wasn't sure if there was a configuration setting for that, or if you wanted me to add one. Any and all feedback welcome. Or if it seems reasonable as-is, let me know and I'll set up a pull request. Thanks!

moodboom/i3@9333774#diff-75bd1443560c3507928c1f5d5d351e21

@moodboom

This comment has been minimized.

moodboom commented Mar 21, 2018

btw it's working great here and really fun to use :-) i reduced min pct to 5%.

@orestisf1993

This comment has been minimized.

Member

orestisf1993 commented Mar 21, 2018

Without looking at the implementation details:

  1. The PR page is generally a better place to review changes
  2. Make sure to remove personal files when you submit your pr (eg .idea/)
  3. If this is a core i3 feature you'll need to use the next branch of this repository, not the i3-gaps one.
@Airblader

This comment has been minimized.

Member

Airblader commented Mar 21, 2018

Yeah, please set up the PR first so we can discuss it there.

@moodboom

This comment has been minimized.

moodboom commented Mar 21, 2018

Thanks all, here's the PR: #3194

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment