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

Progress bar as notification background #318

Closed
k80w opened this issue Apr 11, 2017 · 7 comments
Closed

Progress bar as notification background #318

k80w opened this issue Apr 11, 2017 · 7 comments

Comments

@k80w
Copy link

k80w commented Apr 11, 2017

Being able to use the value of %p to fill the background like a progress would be cool (i.e. with a 25% progress value, the left quarter of the notification could be filled brighter than the rest)

@k80w
Copy link
Author

k80w commented Jul 22, 2017

Figured I'd see if I could figure out how to implement this myself. I've literally never written anything in C before, so I couldn't figure out how to add configuration options for the color and stuff (right now it just uses a slightly brighter background color), but I got a simple progress bar working if anyone really wants one enough to use a crappy fork.

@bebehei
Copy link
Member

bebehei commented Jul 22, 2017

Hey, I tested your fork, it does not respect the shrink option. If the volume is 100 percent, the bar is actually at 50 percent. It seems to work fine if shrink is not set. That's wrong, see the follow up comment.

Also I would not use the full height of the notification as progress bar. As a quick hack, I used bg_height/8 and it looks much nicer. (I hope you use a much more sophisticated algorithm to determine the progress bar height.)

Adding options has to be done in multiple files, but can be done straight forward. But I don't know if it's worth adding an option for it. IMHO I would just simply add it as a new feature without configuration.

@bebehei
Copy link
Member

bebehei commented Jul 22, 2017

It's a simple order of action bug:

Look at bg_width / 100 * (cl->n->progress - 1):

If I deactivate shrink, my notifications are 300px wide. So 300/100 == 3 and times the progress bar, this determines the width. All fine.

If I activate shrink, my notification with progress bar get shrinked to 185px width. Here is 185/100 == 1. Actually it's 1.85, but the bits behind the comma get truncated. The error is almost the half, which explains the 50%.

Changing the order (first multiplying and then dividing) will solve the issue.

@k80w
Copy link
Author

k80w commented Jul 22, 2017

@bebehei Thanks for the help! I updated my fork. I'd submit a PR, but I feel like at the very least I'd want to have a configuration option to enable/disable progress bars first... I guess I'll look into that later and see if I can figure it out.

@mid-kid
Copy link

mid-kid commented Aug 4, 2017

The title of this issue gave me the wrong expectations as to what your patch did. So, I decided I could make it fancier:

Here's the patch:

diff --git a/src/x11/x.c b/src/x11/x.c
index 9f7ac20..3430892 100644
--- a/src/x11/x.c
+++ b/src/x11/x.c
@@ -565,14 +565,22 @@ static dimension_t x_render_layout(cairo_t *c, colored_layout *cl, colored_layou
         double bg_half_height = settings.notification_height/2.0;
         int pango_offset = (int) floor(h/2.0);
 
+        int progress_width = cl->n->progress > 0 ? bg_width * (cl->n->progress - 1) / 100 : bg_width;
+
         if (first) bg_height += settings.frame_width;
         if (last) bg_height += settings.frame_width;
         else bg_height += settings.separator_height;
 
         cairo_set_source_rgb(c, cl->frame.r, cl->frame.g, cl->frame.b);
-        cairo_rectangle(c, bg_x, bg_y, bg_width, bg_height);
+        cairo_rectangle(c, bg_x, bg_y, progress_width, bg_height);
         cairo_fill(c);
 
+        if (progress_width != bg_width) {
+                cairo_set_source_rgb(c, cl->frame.r - 0.2, cl->frame.g - 0.2, cl->frame.b - 0.2);
+                cairo_rectangle(c, bg_x + progress_width, bg_y, bg_width - progress_width, bg_height);
+                cairo_fill(c);
+        }
+
         /* adding frame */
         bg_x += settings.frame_width;
         if (first) {
@@ -582,13 +590,26 @@ static dimension_t x_render_layout(cairo_t *c, colored_layout *cl, colored_layou
                 if (!last) bg_height -= settings.separator_height;
         }
         bg_width -= 2 * settings.frame_width;
+        if (progress_width < settings.frame_width) {
+                progress_width = 0;
+        } else if (progress_width - settings.frame_width > bg_width) {
+                progress_width = bg_width;
+        } else {
+                progress_width -= settings.frame_width;
+        }
         if (last)
                 bg_height -= settings.frame_width;
 
         cairo_set_source_rgb(c, cl->bg.r, cl->bg.g, cl->bg.b);
-        cairo_rectangle(c, bg_x, bg_y, bg_width, bg_height);
+        cairo_rectangle(c, bg_x, bg_y, progress_width, bg_height);
         cairo_fill(c);
 
+        if (progress_width != bg_width) {
+                cairo_set_source_rgb(c, cl->bg.r - 0.2, cl->bg.g - 0.2, cl->bg.b - 0.2);
+                cairo_rectangle(c, bg_x + progress_width, bg_y, bg_width - progress_width, bg_height);
+                cairo_fill(c);
+        }
+
         bool use_padding = settings.notification_height <= (2 * settings.padding) + h;
         if (use_padding)
             dim.y += settings.padding;

@bebehei
Copy link
Member

bebehei commented Aug 4, 2017

@mid-kid Well, I think it's oneself's definition of "what is fancy". We all have some different taste. I personally dislike it to have the full width in background. But thanks for your submission. I never thought of changing the frame color.

Actually, what I'm eager to search for, are some meaningful options to give everyone the ability to specify a geometry for their own progress bar.

@tsipinakis
Copy link
Member

#775 was merged, I'll consider this solved.

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

No branches or pull requests

4 participants