Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Better handling of stack/tab swamps #3738
I'm submitting a…
[ ] Bug [x] Feature Request [ ] Documentation Request [ ] Other (Please describe in detail)
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
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:
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).
As I described #3724, I suggest the following:
This will effectively reduce the asymptotic worst run-time complexity of tab/swamp jumping down to O(1) from O(n).
- Linux Distribution & Version: archlinux - Are you using a compositor (e.g., xcompmgr or compton): compton
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.
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.
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.
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.