Closed ghost closed 4 years ago
I don't really see a point for that in a tiling WM, but tastes differ. However, I'm not looking to add something like that to i3-gaps, no. If you do write a patch for it feel free to show it here anyway though, if it turns out to be surprisingly easy to implement I might reconsider.
It seems like a lot of people would like this: reddit post
Would you perhaps consider it as an option for floating windows?
AFAIK a mandatory prerequisite for this would be support of the Shape extension (correct me if I'm wrong). This has in theory been accepted upstream, so once someone landed that in i3 we could think about revisiting rounded corners. I'm definitely not willing to add Shape only in i3-gaps as that's likely a lot of maintenance overhead.
Any updates on this? This is something I'm really looking forward to.
I'd like this feature as well! would look great with the gaps extension on i3!
Hello there, I landed on this issue while looking for making windows corners rounded a little, After reading the thread I was thinking maybe adding the feature doesn't require a lot of expertise? so if someone can explain how this would be implemented I can experiment a little on my machine, maybe come up with an implementation that is sufficient for most people?
So @Airblader Is there an implementation in mind you think will fit the current code structure?
As stated above, the first step IMHO is to support Shape in i3.
Just to make sure we're on the same page, you're referring to this https://www.x.org/releases/X11R7.7/doc/xextproto/shape.html
correct?
Yes, that's the extension.
any news about this feature ?
Shape has landed in i3. Specifically regarding rounded corners there's no news.
Would be interesting to see, I think.
Please don't comment unless there's information to add. Each comment sends an email to everyone watching this issue. If you just want to voice support, you can do with reaction emojis. Thanks!
There is a fork, where some user tried to implement rounded corners: https://github.com/resloved/i3
Reddit thread (with scrot) here: https://www.reddit.com/r/unixporn/comments/8i8ik6/i3gaps_hacky_i3_rounded_titlebar/
And here the changes on the fork: https://github.com/resloved/i3/commit/83a12f774f8fc177ac459f5abbcef4a347e7319c
Can someone confirm this might be the right approach? Unfortunatelly I'm not too fit in C, but maybe this will help someone out here.
Weird to see my fork in this thread, but I wouldn't really suggest it to anyone. When I originally made the changes I knew essentially nothing about X or Cairo so the implementation is really naive. Might have to look into it again since shape is finally here.
Got it to work!
It's just a reimplementation of this bspwm patch: https://github.com/Javyre/bspwm/commit/6ccad79a927387780e497c4c613067286989984b
You can find my changes here: https://github.com/resloved/i3/commit/3a60c56087cc0f981f5b62f73d22697d9a4cca0d
I'm sure there are quite of few issues that still need to be handled (I can think of full screen windows), but for the most part it's the same aliased rounded corner implementation most window managers have.
Well if that isn't a Happy Easter present! Those borders look awesome-sexy! Thanks for your work
Rounded corners still look a bit cut-off when using a high-contrast color and a small border width:
Anything with a border width higher than 3 or simply a color that doesn't have a strong contrast looks delicious, though.
Maybe add another x-pixel-smaller circle in the favored color?
Man am I happy to see this progress!
Thank you very much for implementing this - it looks great! I've noticed that in "tabbed" mode, the tabs are above the rounded window.
From one side, this makes sense. The window itself has rounded corners, but the window decoration remains unchanged. The same would happen if the containers were stacked.
Therefore, the bottom of the windows should always be rounded, but the top should only be rounded if not in tabbed or stacked modes, and the decoration should have rounded corners accordingly.
Just pushed an update that removes the rounded corners on full-screen: https://github.com/resloved/i3/commit/b9e7a0bdf9d9baed15581e2950ef3b48ef07e96c
The issue @DomHudson mentioned happens whenever a window has a title bar, not just in tabbed mode. It would make sense to just round the decoration like @facocalj suggested, but what if the title bar is smaller then the set radius?
Is there a container that includes both the window and decorations? That would make this much easier.
Why do the corners look so incredibly jagged in almost all rounded-corner implementations I've seen, except from on macOS? How could one even anti-alias window borders?
@Demonstrandum The shape extension uses an array of 1s and 0s (1-bit pixmap) to define what pixels are supposed to be masked or kept. It doesn't allow for any level of transparency that would be needed to anti-alias the edge. From what I've read it seems to just be a limitation of X.
@resloved Nice work! FYI, you may want to disable rounded corners when in tabbed mode, too. They look a little strange below the tab bar, but certainly not unusable.
Can we draw only the bottom two corners round for the tabbed mode? 🤔
I've pushed an update that prevents the top corners from being rounded when there is a title bar. This includes stacked and tabbed layouts, as well as when the border is set to 'normal' instead of 'pixel'.
If you notice any issues let me know! I guess rounding the title bar itself is next on the list.
@resloved this is just awesome! Do you already have a solution approach with a higher configured corner radius than the title bar is height?
First of all, thanks to @resloved for all his efforts! I forked his repository and played a bit with roundness, check what I've got here:
The important bits are here: https://github.com/facocalj/i3/commit/a9af5b595b3665c2c1d576e3c69cb6a587426677 But please check the latest commit for a fully working version.
@resloved You added shaping to the containers inside the recursive call to draw decorations (x_deco_recurse), I added shaping to the titles right after the recursive call, so all the decorations are in place. I tried to use a single function to shape both, but for some reason, the shaping to containers has to be applied inside this recursive call, otherwise stacked containers don't get the bottom round corners.
Please let me know what you guys think!
Great job @facocalj!
With your fork, I noticed that it is possible to accidentally end up with a window with the top square but the bottom rounded. If you create two windows, change them to tabbed/tiled, then close one of the windows - the remaining window doesn't have the top rounded. Believe this is due to the cache.
I've pushed a new update based on @facocalj implementation: https://github.com/resloved/i3/commit/81ae7b0363c8686545afe6011d6de5c039ea956e
I've reworked x_shape_window
to position the rounded corner based on the decoration height. In the case of a title bar the rounded corner is outside the frame and will not be drawn, if the title bar has no height the rounded corner will be drawn normally, if the height of the title bar is in between it will draw partially for both the title and window. In other words -- you can use whatever font size for your title now.
I have encountered issues still:
I played a bit with @resloved's updated fork and I got a somewhat similar broken result:
(compton helped me to see the distinction between containers)
What should be the excepted behaviour of the rounded corners in a more complex tabbed/stacked + split layout? Should we only round the top and bottom corners of a window, or should we round all the corners of all containers regardless of their placement?
The former option could potentially be achieved with a new flag in con_state
, to indicate whether the given container is already inside a rounded parent, and therefore skip the shaping.
The latter option raises a new question, how should we fill the rounded corner "gap"? Transparency, solid color?
I fixed the rounding of the inner titles, as well as the top edge of containers: But I couldn't find a way not to round the bottom edge of a container in case there is a title bar below the container.
The commit https://github.com/facocalj/i3/commit/4632608346395d93fc4d311d934030062947e7bb might fix the issue raised by @resloved
How does it look with borders?
@slole Borders look like this:
This does bring up the issue of using borders that are smaller then the corner radius allows for:
The simplest solution I could think of was drawing the border corner over the window, but I'm not sure if that's always appropriate.
What about drawing the border around the curve (both the border and window would be curved)? Or would that require drawing over the window?
From my understanding, that would require the border to be a separate window and I'd rather not restructure how it's handled currently.
Thanks for the clear-up
@Airblader Do you have intentions to re-open this issue? I think it's now in active development and being open it maybe attracts more people to it. If this feature is not going to be implemented in i3-gaps anyway, maybe @resloved should consider having issues on his fork :)
I will reopen for now, but would suggest that @resloved either opens a Draft PR or maintains it in a fork (whichever they prefer) as reviewing linked commits is a bit tedious. I'm happy to give it a quick look in a PR where we can see all changes and comment on individual parts.
My main concern is keeping the changes local enough to make sure i3-gaps can be synchronized from upstream easily enough (this is my No. 1 goal with i3-gaps). So all of the Shape logic could be moved to a separate file as this avoids merge conflicts. In terms of how the shaping is hooked into rendering I'd have to think & review it still.
Thanks for reconsidering!
Regarding the hooks, that is actually something that I started to wonder over the weekend. Playing with the corners inside x.c
doesn't feel quite right, as we are doing a lot of effort to handle edge cases of title bars and splits. Maybe something called in render.c
, e.g., inside render_con
like the gaps, would be the right way to go.
I was going to wait until we squashed some of the larger issues, but you're right its getting a bit messy in here.
Here's the draft pull request: https://github.com/Airblader/i3/pull/294
Are you finding that the shadows are drawn beneath the tabs on tabbed/stacked mode? This is on resloved's most recent commit. Had a quick look and haven't worked out why this has started happening yet.
Shadows are likely gonna be difficult to support properly given the unconventional way i3 renders decorations.
I have installed the Arch package i3-gaps-rounded-git and removed the old i3-gaps package, yet my corners are not round. Is there something I need to configure in i3config?
@OblongCheese As of 001816781d591bd0038fb8a3e637743b16987aa9 you can set the corner radius via i3config. Just use border_radius x
where x is the size of the radius (People seem to like 4).
In the future if anyone needs support related to rounded corners DM me on reddit (/u/resloves) or make an issue on my fork instead of adding more clutter to this issue.
Hi, I have issue that some of configuration (including border_radius
) doesn't work.
I am on arch and I installed i3-gaps
gaps inner all set 20
gaps outer top 5
border_radius 5
All of these 3 don't work, but when I install i3-gaps-rounded-git
, border_radius
works, but again gaps inner all set 20
and gaps outer top 5
doesn't. Also it works when I set it to gaps inner 20
, but I don't know how to set it to top-only gap.
Thanks in advance.
It would be really nice to have this integrated directly into i3-gaps
@GrbavaCigla I assume this is a result of my fork being out of date compared to upstream. I'm not really in a place where I want to automatically update my fork in case a merge goes south, so for the time being I would suggest forking resloved/i3 and merging with the up to date airblader/i3 yourself.
@grravity From my understanding airblader is still working on getting i3-gaps merged into core i3, so he isn't merging any pull requests (which is totally reasonable).
Why don't you guys just merge it into this project, instead of keeping border_radius on a separate fork?
Closing this issue now that the PR has been closed as well. Please find the rationale I gave there.
Rounded corners are super sexy. There are patches for some floating wms (I know about Openbox, Fluxbox and FVWM). Is there any chance of implementing them in i3?