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

[Umbrella] Support gaps #3724

Open
Airblader opened this issue Jun 17, 2019 · 12 comments

Comments

Projects
None yet
7 participants
@Airblader
Copy link
Member

commented Jun 17, 2019

I'm submitting a…

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

Desired Behavior

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:

  1. This is not about simply porting the gaps patch into i3. The current gaps patch is kept simple enough to make upstream maintenance possible; this means, however, that in many ways it is more of a hack and doesn't live up to our quality expectations. We should therefore consider – and discuss – how gaps can be brought into i3 in a clean way, particularly including support for titlebars.
  2. At this point in time, there is no final decision on whether we would merge this. It very much depends on the discussion and the solution we can find.

Gaps

This list tracks the core gaps features that need to be supported

  • Configuration: gaps [inner|outer|horizontal|vertical|top|left|bottom|right] <px>
  • Configuration: workspace <ws> gaps [inner|outer|horizontal|vertical|top|left|bottom|right] <px>
  • Command: gaps inner|outer|horizontal|vertical|top|right|bottom|left current|all set|plus|minus|toggle <px>
  • Make gaps information properly available on the IPC (required for in-place restart)
  • Ensure gaps work with titlebars
  • Provide tests for gaps

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.

Gaps-related features

The following list tracks other features that need to be supported in i3 as well¹.

  • smart_gaps on | inverse_outer
  • smart_borders no_gaps²
  • hide_edge_borders smart_no_gaps

¹ Note that we may choose to rename features if necessary.
² smart_borders on is an alias for hide_edge_borders smart and will thus be ignored here.

Linking related issues for visibility: #1474, #3611, #2890

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!

Environment

Output of i3 --moreversion 2>&-:

i3 version: 4.16.1
@Airblader

This comment has been minimized.

Copy link
Member Author

commented Jun 17, 2019

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.

@rndusr

This comment was marked as off-topic.

Copy link

commented Jun 17, 2019

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 smart_gaps option correctly. Would that allow me to limit the size of single windows? If not, would it be something worth implementing?

@Natureshadow

This comment was marked as off-topic.

Copy link

commented Jun 17, 2019

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!

@Airblader

This comment was marked as resolved.

Copy link
Member Author

commented Jun 18, 2019

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.

@stapelberg

This comment has been minimized.

Copy link
Member

commented Jun 18, 2019

Ideally gaps would not require a compositor.

I’d like to make this requirement a bit stronger: gaps between windows must be possible with or without a compositor. For advanced features like transparency, a compositor may be required (I don’t know).

@Airblader

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2019

@skontar The non-gaps related issues have separate issues, see #3721

@budRich

This comment was marked as off-topic.

Copy link

commented Jun 18, 2019

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 .


i3-less

  • no gaps
  • no internal managing of keybindings
  • no internal bar
@xPMo

This comment has been minimized.

Copy link

commented Jun 18, 2019

Given the work the Sway folks have put in implementing gaps (and other i3-gaps features) "correctly" from the start, is the sway project a good place to refer for implementation? Or is compositing too integrated in that project for i3?

@Airblader

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2019

I have no idea how sway or Wayland work but my feeling is that it wouldn't be very useful.

@Al-Caveman

This comment has been minimized.

Copy link

commented Jul 15, 2019

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:

  1. Tabs initially work as normal tabs in i3.
  2. When number of tabs increase beyond certain limits, or if title's text gets squeezes up to certain limit, then simply add another tabs row. Alternatively, one could manually create a new tabs row.

Additionally, I suggest this usability enhancement: make tabbed windows as a single browsing unit, so when we use mod+left/right/top/down, we don't end up shuffling tabs, and we don't end up hitting a moment "Oh I should've selected all, by mod+a+a...+a first!". Instead, we use other key combinations specific for tab shuffling. This is more usable than needing to hit mod+a every time one wants to move across a tabbed tile without wanting to also shuffle the tab. IMO it is better to isolate (1) tile movement from (2) tab shuffling.

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 mod+up and mod+down keys. But I suspect that most people will not do so.

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.

@stapelberg

This comment has been minimized.

Copy link
Member

commented Jul 15, 2019

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:

  1. Tabs initially work as normal tabs in i3.
  2. When number of tabs increase beyond certain limits, or if title's text gets squeezes up to certain limit, then simply add another tabs row. Alternatively, one could manually create a new tabs row.

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 :)

Thank you.

@Airblader

This comment has been minimized.

Copy link
Member Author

commented Jul 15, 2019

What @stapelberg said, but with the addition that the first part of your comment (thanks for that!) seems to be #1966, I think.

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