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

Set radius for each window's corner #4386

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

Micovec
Copy link
Contributor

@Micovec Micovec commented Jan 8, 2024

Describe your PR, what does it fix/add?

This PR opens a possibility to define a radius for each window's corner separately. This can come as a new way for ricing Hyprland in combination of modified hyprwm/hyprland-plugins/hyprbars (please don't judge color scheming, I set them to have a high contrast).

image

As you can see window has rounded corners only at the bottom and hyprbars only at the top. They become more unified and it actually seems like hyprbars is part of the window.

Rounding has additional definition:

decoration {
    rounding = 15 # old way
    rounding = 0,0,15,15 # new way: topLeft, topRight, bottomRight, bottomLeft
}

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

However it is not done yet and there are still some issues. For example: window border isn't part of the bar (in picture set to size 7) as it still renders around the original window and not around hyprbars.

image

On top of that as you can see (in highlighted red rectangle) the border is rounded even though radius is set to 0. To keep it consistent there shouldn't be any rounding.

When merged it will break hyprwm/hyprland-plugins/hyprbars and hyprwm/hyprland-plugins/borders-plus-plus as they rely on CWindow::rounding() and not the changed CWindow::getCornerRadii().

Also I'm not sure if substraction box for renderdata.damage has correct values. I've left a TODO comment there.

Is it ready for merging, or does it need work?

PR is not ready for merging. I just wanted to see if it's a valid feature to add into Hyprland and if there's any interest for it.

If it will be decided to merge this, I'll make another PR into hyprwm/hyprland-plugins to fix compatibility and rounding.

@Eclextic
Copy link

Eclextic commented Jan 8, 2024

Probably not supported by the API but can one add multiple ways of defining variables, vaxry?
In this example it would be perfect:

decoration {
    rounding = 15 # old way => would become the same as rounding = 15,15,15,15
    rounding = 0,0,15,15 # new way => when needed users can use this syntax
}

@Micovec
Copy link
Contributor Author

Micovec commented Jan 8, 2024

Probably not supported by the API but can one add multiple ways of defining variables, vaxry? In this example it would be perfect:

decoration {
    rounding = 15 # old way => would become the same as rounding = 15,15,15,15
    rounding = 0,0,15,15 # new way => when needed users can use this syntax
}

Yes. I kept the old way of defining rounding with one integer and added a new way with four separated by comma.

This

rounding = 15

then gets mapped as:

rounding = 15,15,15,15

@vaxerski
Copy link
Member

vaxerski commented Jan 8, 2024

@Eclextic already possible.

@cristian-ciobanu
Copy link

This would be a nice addition at least for people who use hyprbars as plugin.

@Eclextic
Copy link

This would be a nice addition at least for people who use hyprbars as plugin.

Pssst... That's what the Author of this MR was eluding to!

@charlesfire
Copy link

I was looking to see if it was possible to set corner-radius on a per-corner basis and I found this merge request. I'm in favor of this feature. Giving more customization options for users, when it doesn't add unnecessary complexity, is always a good thing.

@Micovec
Copy link
Contributor Author

Micovec commented Jun 26, 2024

I was looking to see if it was possible to set corner-radius on a per-corner basis and I found this merge request. I'm in favor of this feature. Giving more customization options for users, when it doesn't add unnecessary complexity, is always a good thing.

I appreciate the support but instead of commenting it's better to give thumbs up to the PR (first comment) so that it's easier to see which PRs are wanted by people.

Currently there's big migration away from wlroots. That includes some changes in rendering. When that's done and polished I'll take a second look on this and will try to finish it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants