Skip to content
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

Better handling of stack/tab swamps #3738

Open
Al-Caveman opened this issue Jul 16, 2019 · 6 comments

Comments

@Al-Caveman
Copy link

commented Jul 16, 2019

I'm submitting a…

[ ] Bug
[x] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

Currently, as far as keyboard-based focus navigation is concerned, tabs/stacks/tiles are all treated like the same thing (tiles), so that when we use keys to navigate tiles, we also end up shuffling tabs/stacks.

The suggested solution by i3 is that we press mod+a+...+a frequently enough, until we select the entire collection of tabs/stacks, then we move around. This has two problems:

  • mod+a+...+a has the asymptotic worst run time complexity of O(n), where n is total number of levels/hierarchies in the tabs/stacks tree. Ideally, if there are m-many windows distributed in a perfectly balanced tree, n=log m, which is still very convenient even in the ideal case for a tabs/stacks user. The only users that do not suffer this, are those who do not use stacks/tabs.

  • It's practically even worse than O(n), because this number assumes that the user does not forget (while paying attention to a more important task) that he is now jumping over a bunch of stacked/tabbed windows. More realistically, what happens in many cases is this:

    1. User tries to move from a tile to another tile on the other screen.
    2. His attention is mainly on that other screen for that other task.
    3. He has forgotten that, in the middle of the path of tile-jumps exists a collection of tabbed/stacked tiles (aka a swamp).
    4. As he is moving to the destination tile on the other screen, he crosses that swamp and gets stuck for a while.
    5. He gets slowed down in that swamp, as he does this:
      1. Accidentally shuffles some stacks/tabs,
      2. Then corrects them,
      3. Then presses mod+a+...+a, with that annoying O(n) to finally make a clean jump out of the swamp of stacks/tabs.

We might call the current behaviour to be "having stack/tile swamps". I am very confident that tabs/stacks are semantically useful features, which makes me wonder, which one came first:

  • Did most users abandon stacks/tiles because they don't need them?
  • Or did they abandon them because of the stacks/tabs swamps? I conjecture this came first for most users (and I confirm it is my case). But, unlike users that have the liberty of being able to ignore stacks/tabs, I cannot due to my workflow. So currently I use them, and suffer stack/tab swamps.

Note: The mouse-based focus navigation does not suffer tab/stack swamps. We can consider this feature request as the solution to make the keyboard-based focus navigation as good as the mouse-based focus navigation in this regard (handling stack/tab swamps).

Desired Behavior

As I described #3724, I suggest the following:

  • A tile is the box that you see in front of you. Tiles are browsed by, say, mod+up/down/left/right.
  • If a number of tiles are stacked/tabbed, do not treat them as separate, but rather treat them as a merged/grouped set of tiles. This way, when you do mod+up/down/left/right, you do not shuffle the tabs/tacks, but rather jump over the collection of the merged/grouped tabbed/stacked tiles as a single unit.
  • In order to navigate/shuffle tabs/stacks, introduce tab/stack-specific commands, such as, maybe focus up-stack, focus down-stack, focus left-stack, focus right-stack, etc, and the same for *-tab.
  • For backwards compatibility, the default key binding of, say, focus up-stack could be the key binding chosen for focus up. This way, users who like the old behavior will not feel of the change, while others, such as me, will benefit greatly.

This will effectively reduce the asymptotic worst run-time complexity of tab/swamp jumping down to O(1) from O(n).

Environment

i3 4.16.1-1

- Linux Distribution & Version: archlinux
- Are you using a compositor (e.g., xcompmgr or compton): compton
@Airblader

This comment has been minimized.

Copy link
Member

commented Jul 16, 2019

For backwards compatibility, the default key binding of, say, focus up-stack could be the key binding chosen for focus up. This way, users who like the old behavior will not feel of the change, while others, such as me, will benefit greatly.

I don't understand how that preserves compatibility. Most users don't use the shipped default config, but at least a copy thereof, most of the time even modified. If the semantics for a specific command change, it's a breaking change, no matter what we put into the default config.

@Al-Caveman

This comment has been minimized.

Copy link
Author

commented Jul 16, 2019

Sorry, what I mean is this: the key that is bound to the command, say, focus up-stack, if undefined in the config, to be automatically chosen to be the same key as the chosen one for focus up (regardless of how the binding of focus up is chosen).

@Airblader

This comment has been minimized.

Copy link
Member

commented Jul 16, 2019

The – only – place of truth should be the config. I don't think we'd want to start binding keys automatically if they are free in the config or anything like that. It's also not that easy to detect that as that command might be chained with others or be executed indirectly through a script etc.

@Al-Caveman

This comment has been minimized.

Copy link
Author

commented Jul 18, 2019

I agree. So backwards compatibility is not possible.

Can we ignore this backwards compatibility? And just add normal classical defaults for the new commands that I suggested? Then, users who love their tab/stack swamps, they could just add extra config lines to get their swamps back if they love them so much.

In my view, this change brings an undeniable improvement to the usability of i3. I personally think it's worth this little annoyance to swamp lovers. They can get their swamps by changing the config default of the new commands.

@Airblader

This comment has been minimized.

Copy link
Member

commented Jul 18, 2019

Can we ignore this backwards compatibility?

No, breaking compatibility in such basic functionality is not an option in my opinion. I don't see the benefit nearly as drastic as you, but even if it was, I wouldn't be willing to sacrifice the compatibility for it. It's a large core value of i3 to keep important functionality stable.

Rolling out such a change, we'd probably get dozens of issues, emails and reddit threads of upset users. Not a good thing. :-)

So if anything (but this is in no way me saying "yes" to the proposed feature, I haven't had time to look into it in detail) we'd have to introduce new commands for the new behavior and anyone wanting to adopt them could change their configs appropriately.

@Al-Caveman

This comment has been minimized.

Copy link
Author

commented Jul 20, 2019

Dude please do that, make it a "yes". Else, help me create i3-gaps-swamp fork plz (will take me too long tho).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.