GNOME Bugzilla – Bug 624383
multipoint gradients
Last modified: 2021-07-05 14:05:02 UTC
The current linear gradient CSS-like property only allows to define a start point and endpoint. For things like entry widgets, it would be beneficial to be able to define multiple color nodes. Ideally this should use the syntax proposed for CSS3 rather than our own, allowing arbirary angle as well -- http://dev.w3.org/csswg/css3-images/#linear-gradients. But I'm fine with having our own properties.
*** Bug 587003 has been marked as a duplicate of this bug. ***
Created attachment 178443 [details] [review] Patch to add some CSS3 features support This is a big patch with three features adding: - linear/radial-gradient - background-position - background-size Comments added to corresponding bugs.
(In reply to comment #2) > This is a big patch with three features adding: > - linear/radial-gradient > - background-position > - background-size ... so it should be a minimum of three patches. Seriously, can you split this up?
Created attachment 178450 [details] [review] Implementation of CSS3 gradients Splitted patch for CSS3 gradients feature This patch needs background-position from bug 633460.
Created attachment 178531 [details] [review] Implementation of CSS3 gradients Little corrections to the background clean part.
Created attachment 178558 [details] [review] Implementation of CSS3 gradients Forgot StThemeNode -private.h change
Created attachment 178716 [details] [review] Implementation of CSS3 gradients Rebase on top of the new background-size
Created attachment 178718 [details] [review] Implementation of CSS3 gradients (background and background-image properties) Oops, forgot I add gradients to background-image (so didn't test to compile it).
Review of attachment 178718 [details] [review]: Good. Just watch your code style, we're using GNU for our C code. This means that blocks look like: if (foo) { bar = 1; } and parenthesis need a space before them. ::: src/st/st-gradient.c @@ +22,3 @@ + +StGradient * +st_gradient_new(StGradientType type) Is there any reason we're not using a full GObject here? @@ +116,3 @@ + +void +st_gradient_set_rx(StGradient *gradient, gdouble r) Some documentation on what "rx" and "ry" mean would be useful. @@ +139,3 @@ + return; + + if (offset>100) Might want a comment defining what "100" is, with a reference to a W3C primary source if possible. ::: src/st/st-theme-node-drawing.c @@ +474,3 @@ } +#define DISTANCE(x0, y0, x1, y1) (sqrt((fabs(x1-x0)*fabs(x1-x0))+(fabs(y1-y0)*fabs(y1-y0)))) I don't think we really want a sqrt here. If we're trying to get the minimum distance, won't a Manhattan work just as well? @@ +538,3 @@ + gdouble h, v; + gdouble tl, tr, br, bl; + gdouble sx = 1, sy = 1; Can you use more descriptive variable names?
Created attachment 191653 [details] [review] Implementation of CSS3 gradients (background and background-image properties) Real patch here. That's the last time I promise. The patch (as the others) is just the last one I rebased, no review comment integrated yet, you may not repeat yourself so. (In reply to comment #9) > Review of attachment 178718 [details] [review]: > > Good. Just watch your code style, we're using GNU for our C code. This means > that blocks look like: > > if (foo) > { > bar = 1; > } > > and parenthesis need a space before them. I will try, that's definitely not my favorite style. > ::: src/st/st-gradient.c > @@ +22,3 @@ > + > +StGradient * > +st_gradient_new(StGradientType type) > > Is there any reason we're not using a full GObject here? Not sure, I think I copied the other ST struct way to do. > @@ +116,3 @@ > + > +void > +st_gradient_set_rx(StGradient *gradient, gdouble r) > > Some documentation on what "rx" and "ry" mean would be useful. > > @@ +139,3 @@ > + return; > + > + if (offset>100) > > Might want a comment defining what "100" is, with a reference to a W3C primary > source if possible. Noted. > ::: src/st/st-theme-node-drawing.c > @@ +474,3 @@ > } > > +#define DISTANCE(x0, y0, x1, y1) > (sqrt((fabs(x1-x0)*fabs(x1-x0))+(fabs(y1-y0)*fabs(y1-y0)))) > > I don't think we really want a sqrt here. If we're trying to get the minimum > distance, won't a Manhattan work just as well? I didn't know the Manhattan distance, so something that simple would work? #define DISTANCE(x0, y0, x1, y1) (fabs(x1-x0)+fabs(y1-y0)) Interesting, just need some tests, I hope. > @@ +538,3 @@ > + gdouble h, v; > + gdouble tl, tr, br, bl; > + gdouble sx = 1, sy = 1; > > Can you use more descriptive variable names? Yes, we can. I might delegate the tests right now, until I got some gnome-shell environment to test it myself (not at home).
> I didn't know the Manhattan distance, so something that simple would work? > #define DISTANCE(x0, y0, x1, y1) (fabs(x1-x0)+fabs(y1-y0)) A Manhattan difference has a different locus than a Euclidian one: the former is a diamond, the latter is a circle. I'm not sure it matters when finding the closest/farthest corner of a rectangle. But since we're doing that, why not check the quadrant we're in and let cairo do the math for us? static void closest_corner (int x, int y, int width, int height int *corner_x, int *corner_y) { /* This function assumes that we have a rectangle from (0, 0) * to (width, height) and that (x, y) is in that rectangle. */ if (corner_x) { if (x <= (width / 2)) *corner_x = 0; else *corner_x = width; } if (corner_y) { if (y <= (height / 2)) *corner_y = 0; else *corner_y = height; } } and int corner_x, corner_y; get_closest_corner (x, y, width, height, &corner_x, &corner_y); pattern = cairo_pattern_create_radial (x, y, 0, corner_x, corner_y, 0);
*** Bug 737789 has been marked as a duplicate of this bug. ***
The duplicate I f(a)iled tried to emphasize the benefit of having the same way to define gradients across Adwaita gtk and the shell.
*** Bug 787434 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.