Rounded Corners

[georglauterbach]

I'm submitting a…

• Bug
• Feature Request
• Documentation Request
• Other (Please describe in detail)

Current Behavior

Window corners are square, always.

Desired Behavior

I'd like to configure the border radius of windows in order to get rounded corners.

Impact

• This feature requires new configuration and/or commands

A compositor like Picom can actually achieve this as well. But there is a plethora of forks of Picom (which itself is a fork of Compton) and this makes it hard to look though and hard to configure. There already was an issue about this in the i3-gaps repository (i3-gaps#167) - maybe this helps maintainers.

The rationale of @Airblader was not to add a new feature to i3-gaps in order to allow merging it into i3 some day. Now that this day has come, and all is merged, maybe we can look at rounded corners again? :) I do believe this is a feature the community would love to see ❤️

If it turns out that the complexity added by this feature does not outweigh its benefits, and makes maintaining difficult (believe me, I know that maintainability is something serious), I understand that this feature is not going to be implemented. I'd love to see it though!

Environment

• Linux Distribution & Version: Regolith Linux 2.0 on Ubuntu (basically GNOME with i3 being the window manager instead of Mutter)
• Are you using a compositor (e.g., xcompmgr or compton): (I think Regolith uses) Picom

[i3bot]

Please note that new features which require additional configuration will usually not be considered. We are happy with the feature set of i3 and want to focus in fixing bugs instead. We do accept feature requests, however, and will evaluate whether the added benefit (clearly) outweighs the complexity it adds to i3.

Keep in mind that i3 provides a powerful way to interact with it through its IPC interface: https://i3wm.org/docs/ipc.html.

[georglauterbach]

ping @stapelberg @Airblader

[Airblader]

I'm frankly just not up to date on the effort involved and how well it works. Evidently, rounded corners has a lot of support from the community; unlike gaps, I still see it as a minor visual change without any meaningful impact, so that does raise the bar a bit for me.

I'm also somewhat out of the loop with the community. I think it'd be great if someone could summarize the current situation, is is there a fork that is most widely used, does it have any limitations or known issues, ...

[georglauterbach]

is is there a fork that is most widely used

I know of https://github.com/terroo/i3-radius, but the other questions I cannot confidently answer.

[stapelberg]

Looks like terroo/i3-radius uses the X11 shape extension.

I also don’t know what the pros/cons of the shape extension are — does it have any issues, is there precedent in other window managers using it?

In general, for the i3-gaps merge it really helped that @Airblader is also a core i3 maintainer.

I’m not saying we would commit to merging rounded corners, but at the minimum, we’d need someone who has some experience with the rounded corner implementation to work with us.

[georglauterbach]

I completely understand! Maybe @terroo has more information on this for us? I am unable to also maintain code here since I am maintaining another project, but I do hope we get some folks from the community to add what they know here.

There also seems to be https://github.com/jbenden/i3-gaps-rounded. Maybe @jbenden has information for us as well :)

[jbenden]

I've been maintaining my fork for some time now. If a MR is desired, I can try and polish the code further for inclusion; along with opening a new PR for it. I'm open!

[georglauterbach]

I've been maintaining my fork for some time now. If a MR is desired, I can try and polish the code further for inclusion; along with opening a new PR for it. I'm open!

❤️

---

Could you give us an estimate how big the change would be? And is maintaining the code a big effort?

[jbenden]

The added code isn't too much... A lot of changes mentioned below would not apply here. I can still maintain the bits to it, if needed or desired.

λ git diff --stat upstream/stable..HEAD
   .github/ISSUE_TEMPLATE.md                    |   3 ++
   .github/workflows/main.yml                   |  44 ++++++++-----------------
   .gitignore                                   |   2 ++
   README.md                                    | 144 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
  -
   debian/changelog                             |   5 ++-
   docs/userguide                               |  17 ++++++++++
   include/con.h                                |   7 ++++
   include/config_directives.h                  |   1 +
   include/configuration.h                      |   3 ++
   include/data.h                               |   2 ++
   include/gaps.h                               |   5 ---
   include/render.h                             |   2 +-
   parser-specs/commands.spec                   |  17 ++++++++++
   parser-specs/config.spec                     |   6 ++++
   src/commands.c                               |   2 +-
   src/con.c                                    |  42 ++++++++++++++++++++++++
   src/config_directives.c                      |   4 +++
   src/floating.c                               |   6 ++--
   src/gaps.c                                   |  33 -------------------
   src/manage.c                                 |   4 +--
   src/render.c                                 |  63 +++++++++++++++++++++++++++++++-----
   src/tree.c                                   |   2 +-
   src/workspace.c                              |   7 ++++
   src/x.c                                      | 134 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
   testcases/t/201-config-parser.t              |   1 +
   testcases/t/517-regress-move-direction-ipc.t |  55 -------------------------------
   travis/run-tests.sh                          |   3 ++
   27 files changed, 460 insertions(+), 154 deletions(-)

[jbenden]

The PR #5429 introduces the rounded corners feature on-top of the native gaps support.

[okraits]

The PR #5429 introduces the rounded corners feature on-top of the native gaps support.

Silly question, but: how does it look with title bars (and window icons) and window borders? The screenshot in your repo only shows windows without title bars and without borders.

[jbenden]

Hi!

With a recent change I just pushed to the PR, it now handles all situations as I'd expect (for everything checked). Small disturbance with titlebar+1px solid color highlight cutting off slightly. Lastly, some modes can have a pixel value set that makes no sense with the radius of the corner set; in all these cases, setting a value about as large as corner radius fixes it.

I'd recommend trying the PR with your own configurations to see if you like it well enough! 😃 🧪

[georglauterbach]

ping @stapelberg

[stapelberg]

Sorry, I have no time to look into this currently. If anyone else could review the PR, that’d be great!

[georglauterbach]

Sorry, I have no time to look into this currently. If anyone else could review the PR, that’d be great!

ping @Airblader :)

[georglauterbach]

Can we have this not stall please?

[FelixBrakel]

You can force rounded corners with picom. Only issue it that it may cut off a bit of the i3 window border.

[georglauterbach]

You can force rounded corners with picom. Only issue it that it may cut off a bit of the i3 window border.

Did you read the issue description? This is literally one of my first notes :)

[orestisfl]

Please don't ping in the comments

Sorry, I have no time to look into this currently. If anyone else could review the PR, that’d be great!

This is the current status. If we don't have enough time / volunteers to review then we certainly not in a state where we can maintain a non-trivial feature long-term.

[georglauterbach]

Please don't ping in the comments

Understood!

Sorry, I have no time to look into this currently. If anyone else could review the PR, that’d be great!

This is the current status. If we don't have enough time / volunteers to review then we certainly not in a state where we can maintain a non-trivial feature long-term.

I could review, but that will only bring limited use as I am not a maintainer. From what I can see, the PR's changes are quite nice though, and IMO it'd be a a shame to let this go to waste:) If you want me to, I'll review.

If you are sure the maintainers team is not capable of maintaining this feature (which is absolutely understandable, believe me I know what this feels like), then I'd like to close this issue for now in the interest of tidiness. If ever there comes a time where this is picked up again, we can reopen this.

[georglauterbach]

@jbenden thank you very much for your effort and creating a PR ❤️ It seems the maintainers team of i3 is unable to support and maintain this change though.

I am not someone who can leave issues open until finally something happens sometime in the future, so I will close this. If the above mentioned status quo changes, please ping me, so we can reopen this and start working on it again.

[orestisfl]

Since we haven't rejected the feature and since it has good community support, I prefer for the issue to be open until we can reach a final decision. I know that the speed of i3 development is not particularly exciting, but issues for feature requests like gaps and tiling drag were open for years before finally landing in i3.

[georglauterbach]

I will be switching to Sway with the latest release of Regolith (3.0) soon, so keeping this issue alive for me does not make any sense. Can we please have someone else who is interested in this feature open another tracking issue that references this one so I can close?

[orestisfl]

@georglauterbach Opening new tickets for the same issue is disruptive and makes conversation harder. It doesn't cost you anything to have this ticket open, feel free to unsubscribe from it.

[georglauterbach]

@jbenden I have just had a glance on #5429 but the PR is closed. Could you quickly give me an update on that? :)

[jbenden]

The PR is closed, but that branch+fork is what I locally use... So if a merge is to happen, I'll need to rebase and create a new PR.

[jbenden]

Sorry, I was wrong. I looked at what I locally have and found I use https://github.com/jbenden/i3/tree/rounded

[georglauterbach]

Can you rebase nevertheless and open a new PR? It seems this may be merged after all, even if it takes a bit of time. I may be able to assist a bit in case you need assistance.

[jbenden]

Sure! Let's try again, this time with a most minimal patch... #5686 is the new PR.

[georglauterbach]

For everyone who is interested in this feature, please also have a look at the PR #5686 so we can help @jbenden and the i3 maintainers. Any kind of useful contribution is welcome 🚀❤️