12
167
Fork
You've already forked fnott
32

Add background progress style option #143

Manually merged
dnkl merged 8 commits from e-tho/fnott:master into master 2025年04月18日 10:20:13 +02:00
Contributor
Copy link

This adds a new background progress style that fills the notification background, controlled via the progress-style option taking bar (default) or background.

The progress-bar-color option has been renamed to progress-color to reflect support for both styles. The old name is still accepted with a deprecation warning.

This adds a new background progress style that fills the notification background, controlled via the `progress-style` option taking `bar` (default) or `background`. The `progress-bar-color` option has been renamed to `progress-color` to reflect support for both styles. The old name is still accepted with a deprecation warning. 
Introduce an alternative style where progress fills the notification background.
Controlled via the new 'progress-style' option taking 'bar' (default) or 'background'.
config: Rename progress-bar-color to progress-color
Some checks reported errors
ci/woodpecker/pr/woodpecker Pipeline is pending approval
builds.sr.ht/alpine-x64 Job failed
builds.sr.ht/freebsd-x64 Job failed
dea498063c 
The option now supports both progress styles (bar and background),
making the old name misleading. The old name remains supported
with a deprecation warning.
Author
Contributor
Copy link

Please don't merge this yet.

Despite my efforts, I’ve been unable to achieve pixel-perfect background progress rendering with rounded corners. I’ve tried adjusting the radius calculations (radius_scale = 1.0 - (float)brd_sz / (float)brd_rad) and improving precision (which helps), but I’ve hit the limits of my knowledge.

@ldev105 Could you take a look at it?

**Please don't merge this yet.** Despite my efforts, I’ve been unable to achieve pixel-perfect background progress rendering with rounded corners. I’ve tried adjusting the radius calculations (`radius_scale = 1.0 - (float)brd_sz / (float)brd_rad`) and improving precision (which helps), but I’ve hit the limits of my knowledge. @ldev105 Could you take a look at it?
First-time contributor
Copy link

Please don't merge this yet.

I think you can disable merging of this by prefixing your PR's title with "WIP: ".

WIP: Add background style option

>**Please don't merge this yet.** I think you can disable merging of this by prefixing your PR's title with "WIP: ". `WIP: Add background style option`
e-tho changed title from (削除) Add background progress style option (削除ここまで) to WIP: Add background progress style option 2025年04月11日 14:59:30 +02:00
Contributor
Copy link

I fixed it in #144

I fixed it in #144
Fixed progress style 'background' not taking into account the msaa of
Some checks reported errors
ci/woodpecker/pr/woodpecker Pipeline is pending approval
builds.sr.ht/alpine-x64 Job failed
builds.sr.ht/freebsd-x64 Job failed
ci/woodpecker/pull_request_closed/woodpecker Pipeline is pending approval
af75cfff3f 
the rounded corners.
notification: workaround for background progress width < border radius
Some checks reported errors
ci/woodpecker/pr/woodpecker Pipeline is pending approval
builds.sr.ht/freebsd-x64 Job failed
builds.sr.ht/alpine-x64 Job failed
8a36c09e8d 
Hack to handle cases where the background progress is narrower than the border radius, causing visual glitches and crashes. Ensures stability for very low progress values.
Author
Contributor
Copy link

@ldev105 Two issues were introduced by your refactor:

  • Notifications with a progress value of 0 were causing crashes due to the display of a rectangle with zero width. This is now avoided by checking for values greater than zero.

  • Very low progress values caused crashes or artifacts because the implementation don't properly render the radius of the progress background when it's narrower than the border radius. I applied a temporary workaround by enforcing a minimum width equal to the border radius. This is really not an ideal solution as it locks the progress background to a wide width when using high radius values.

I've given you access to my fork to avoid duplicating PRs

@ldev105 Two issues were introduced by your refactor: - Notifications with a progress value of 0 were causing crashes due to the display of a rectangle with zero width. This is now avoided by checking for values greater than zero. - Very low progress values caused crashes or artifacts because the implementation don't properly render the radius of the progress background when it's narrower than the border radius. I applied a temporary workaround by enforcing a minimum width equal to the border radius. This is really not an ideal solution as it locks the progress background to a wide width when using high radius values. I've given you access to my fork to avoid duplicating PRs
Changed the background progress to use intersecting region's (this fixes crashes
Some checks reported errors
ci/woodpecker/pr/woodpecker Pipeline is pending approval
builds.sr.ht/freebsd-x64 Job failed
builds.sr.ht/alpine-x64 Job failed
382936a392 
when progress is < border radius)
Author
Contributor
Copy link

@ldev105 Amazing work. Thanks for your help on this!

@dnkl This implementation can be reused in Fuzzel to preserve the border radius when no padding is set.

@ldev105 Amazing work. Thanks for your help on this! @dnkl This implementation can be reused in Fuzzel to preserve the border radius when no padding is set.
e-tho changed title from (削除) WIP: Add background progress style option (削除ここまで) to Add background progress style option 2025年04月14日 03:07:41 +02:00
Owner
Copy link

This implementation can be reused in Fuzzel to preserve the border radius when no padding is set.

How? The main issue has been certain font glyphs extending outside the corner. I don't see how anything here would help with that?

> This implementation can be reused in Fuzzel to preserve the border radius when no padding is set. How? The main issue has been certain font glyphs extending outside the corner. I don't see how anything here would help with that?
dnkl left a comment
Copy link

LGTM, except a couple of minor things. Would you also mind adding a changelog entry?

LGTM, except a couple of minor things. Would you also mind adding a changelog entry?
fnott.ini Outdated
@ -45,6 +45,7 @@
# progress-bar-height=20
# progress-bar-color=ffffffff
Owner
Copy link

progress-bar-color -> progress-color

`progress-bar-color` -> `progress-color`
dnkl marked this conversation as resolved
notification.c Outdated
@ -1746,0 +1781,4 @@
return region;
}
static inline void fill_region32(pixman_op_t op, pixman_image_t* dest,
Owner
Copy link

nit:

static inline void fill_region32(...)

nit: `static inline void fill_region32(...) `
dnkl marked this conversation as resolved
Author
Contributor
Copy link

How? The main issue has been certain font glyphs extending outside the corner. I don't see how anything here would help with that?

This should ensure correct rendering of entry backgrounds at the container’s edges, regardless of height or border-radius. I thought this was the only blocking factor.

> How? The main issue has been certain font glyphs extending outside the corner. I don't see how anything here would help with that? This should ensure correct rendering of entry backgrounds at the container’s edges, regardless of height or border-radius. I thought this was the only blocking factor.
Added newline before fill_region32 func and changed progress-bar-color => progress-color in fnott.ini
Some checks reported errors
ci/woodpecker/pr/woodpecker Pipeline is pending approval
builds.sr.ht/freebsd-x64 Job failed
builds.sr.ht/alpine-x64 Job failed
90fa22469e
changelog: background-progress option + ldev, e-tho as contributors
Some checks reported errors
ci/woodpecker/pr/woodpecker Pipeline is pending approval
builds.sr.ht/freebsd-x64 Job failed
builds.sr.ht/alpine-x64 Job failed
ci/woodpecker/pull_request_closed/woodpecker Pipeline is pending approval
16d0da3e38
dnkl manually merged commit f78cf9887e into master 2025年04月18日 10:20:13 +02:00
Owner
Copy link

Thanks, both of you!

Thanks, both of you!
Author
Contributor
Copy link

This closes #134.

This closes #134.
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
dnkl/fnott!143
Reference in a new issue
dnkl/fnott
No description provided.
Delete branch "e-tho/fnott:master"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?