[Umbrella] Support gaps #3724
I'm submitting a…
[ ] Bug [x] Feature Request [ ] Documentation Request [ ] Other (Please describe in detail)
After a recent discussion between @stapelberg and myself, we would like to reconsider bringing gaps into i3 itself, effectively deprecating i3-gaps. The main rationale here is that there clearly are thousands of users who want gaps.
In order to do so, we need to implement not only gaps, but also all of the current i3-gaps features as listed below. This issue serves as an umbrella issue, if necessary we can create separate issues for the individual features. Before work on this can be started, we need to state our expectations:
This list tracks the core gaps features that need to be supported
We should overall strive to be compatible with i3-gaps to minimize friction, but where sensible we may deviate. For example, workspace-level gaps are currently solved a bit awkward in i3-gaps.
The following list tracks other features that need to be supported in i3 as well¹.
¹ Note that we may choose to rename features if necessary.
Please keep the discussion on this issue solely about how to move gaps to i3. Other questions or feature requests should be posted as new issues. As this will likely be a long and technical discussion I will hide any off topic comments. Thank you!
i3 version: 4.16.1
In order to implement gaps properly in i3, I believe #1966 might be a required upfront change. I think ideally a gaps implementation would inset the entire rect of a container rather than just the window_rect (open for discussion, of course). Ideally gaps would not require a compositor.
Interesting things to consider are things like snapping the cursor for resizing and the resize indicator line.
I've always wanted an option that allows me to limit the space a single window can occupy. For example, if I open terminal on an empty workspace, the prompt is at the very top-left corner, which can be awkward to focus on a large monitor. And it will always stay at the left edge, which is also not in the center of my vision. I usually work around this by opening another terminal so that the prompt is at the center, but is that the best solution?
I'm not sure if I understand the
Please bear with me while not posting something technically relevant, but I want to express that I am very much in support of getting this into vanilla i3, also from a distribution point of view. I am very happy that a new contributor in Debian who wanted i3-gaps led to i3-gaps probably being refused into Debian, but new efforts to remove the requirement for it have arisen from it, which will with a bit of luck make life easier for all distributions and users ☺!
Thank you, both upstreams!
I appreciate both your comments, but I would please ask to stay on topic here. This is likely going to be a long and technical discussion, so I would like to avoid +1 noise, questions about how i3-gaps currently works or additional feature requests. This issue is about supporting what i3-gaps can do in i3.
A community is directed by the most intolerant minority. With i3 that used to be @Airblader (on reddit), and @stapelberg (github), that was good (since both of them are good and intelligent people). Now it is ubuntu users who don't know which version they have installed who rule it all.
I will not "upvote" this issue, but i don't dismiss it either.
It is probably a good idea to add gaps to i3. I guess this will mean that i3-gaps will get archived causing less confusion, better package manager support, and most importantly a more focused project workflow for @Airblader .
In my view, title bars should be re-implemented anyway for many reasons. Yet another reason is: better compatibility with other apps, such as GIMP. E.g. taking a screenshot of a window, with windows decoration (in GIMP), does not work, simply because the title bar is a separate window. So the current implementation of title-bars-as-windows is semantically false, and is causing issues with others apps.
I think this would be also a nice opportunity to do things more correctly. Specifically, I think the concepts of stacking and tabbing should be merged. Technically, stacking is just an inefficient tab that needlessly wastes more horizontal space. Tabbing is not perfect either, as it needlessly squeezes too many tabs, up to a point when the text in the title is too unreadable.
I suggest, while re-doing title bars, to introduce smart tabs, which work as follows:
Additionally, I suggest this usability enhancement: make tabbed windows as a single browsing unit, so when we use
As for backwards compatibility, old tabs/stacks could be simply mapped into smart tags. It will be backwards compatible in every sense, except that it will have the side effect of having greater utility per pixel. If a tabbing/stacking-user wants to have maximum backwards compatibility with stacks, he can map the tab-shuffling keys to
Tabbing/stacking are, fundamentally, great features as they map to the concept "minimize" in floating windows (except not needing to fall in the inefficient tasks bar, but rather distribute across the monitor). It's sad that they are not very usable in the current implementation, and hence my suggestions above.
We had this in i3 v3.x and dropped it with the v4.x series. It was a niche feature whose little use didn’t justify the complexity.
As for the rest of your comment, can you post your individual suggestions as separate feature requests please? A grab-bag of thoughts in an unrelated issue is not the best way to have a discussion :)