Expansion of the rounded buttons

[klytje]

With this PR, we can now specify the 'roundedness' of each individual corner of a button.

There are now four ways to control them:

1. Using the existing corner_radius(r) method to specify all corners at once,
2. Using the new overloaded version corner_radius(r1, r2, r3, r4) to specify them indivdually,
3. Using the new rounded_*(r) series of methods to specify a half-rounded side,
4. Using the new rounded_corner_*(r) series of methods to specify individual corners.

I expanded the Buttons example to showcase this new functionality.

I also added a missing implementation of the gen_text_color text_color(color color_) method I discovered during my testing. Previously it could not compile code specifying the text color of buttons.

[djowel]

Looking good. Is this ready for merge? I see some commented out code.

[klytje]

@djowel I added a small corner_radii struct, with initialization order: bottom_right, bottom_left, top_left, top_right. Same as the API I believe.

[djowel]

@djowel I added a small corner_radii struct, with initialization order: bottom_right, bottom_left, top_left, top_right. Same as the API I believe.

Hi @klytje I think the correct sequence is top_left, top_right, bottom_right, bottom_left :-)

Interestingly, if you ask ChatGPT to make an API for drawing a round rectangle with customizable corner radii, it's the one it will recommend:

void draw_round_rectangle(float x, float y, float width, float height,
                          float radius_tl, float radius_tr,
                          float radius_br, float radius_bl);

Then, I asked: "why did you specify the radii from top-left going clockwise?"

ChatGPT follows the large language model from a vast source of programming code, and its answer is:

"Specifying the radii from the top-left corner going clockwise is a common convention in graphics programming. It follows a logical order that aligns with how many people read and interpret shapes and diagrams."

It is indeed customary in computer graphics to give precedence to the top-left, and in general, the horizontal coordinate first (i.e. x, before y).

[klytje]

@djowel I implemented it according to the W3C docs:

"The points at startAngle and endAngle this circle's circumference, measured in radians clockwise from the positive x-axis, are the start and end points respectively."

Indeed, looking at the my implementation you'll see the angle going from 0 --> 90 --> 180 --> 270 --> 360 as it is now:
https://github.com/klytje/elements/blob/round_buttons/lib/src/support/draw_utils.cpp#L99-L104

Your order is what I meant as the third option, following the rect, though looking back it wasn't super clear that was what I meant.

[klytje]

Also I agree that starting from the top-left feels more natural for most objects, except circles :)

[djowel]

@djowel I added a small corner_radii struct, with initialization order: bottom_right, bottom_left, top_left, top_right. Same as the API I believe.

Hi @klytje I think the correct sequence is top_left, top_right, bottom_right, bottom_left :-)

Interestingly, if you ask ChatGPT to make an API for drawing a round rectangle with customizable corner radii, it's the one it will recommend:

void draw_round_rectangle(float x, float y, float width, float height,
                          float radius_tl, float radius_tr,
                          float radius_br, float radius_bl);

Then, I asked: "why did you specify the radii from top-left going clockwise?"

ChatGPT follows the large language model from a vast source of programming code, and its answer is:

"Specifying the radii from the top-left corner going clockwise is a common convention in graphics programming. It follows a logical order that aligns with how many people read and interpret shapes and diagrams."

It is indeed customary in computer graphics to give precedence to the top-left, and in general, the horizontal coordinate first (i.e. x, before y).

BTW, skia goes so far as specify the horizontal and vertical radii for all corners:

https://api.skia.org/classSkRRect.html

But take note of the sequence:

enum Corner { kUpperLeft_Corner , kUpperRight_Corner , kLowerRight_Corner , kLowerLeft_Corner }

[klytje]

Changed initialization order to top_left, top_right, bottom_right, bottom_left.

[djowel]

Changed initialization order to top_left, top_right, bottom_right, bottom_left.

Thanks for your patience! :-)

[djowel]

Ouch. I forgot. This should be against skia_2024 first. Anyway, I'll just do the cherry-pick dance again. No worries.

[djowel]

Oh gee... It seems Skia does arcs differently –not connecting the lines between the arcs!

[djowel]

Oh gee... It seems Skia does arcs differently –not connecting the lines between the arcs!

At least Quartz2D is doing it correctly! I'll push to askia_2024_dev branch. See if you can fix the Artist's Skia implementation of arc to follow W3C's behavior.

[djowel]

BTW, in the demo cpp, I think we should use grids to align the 3 R/G/B buttons properly.

[djowel]

Oh gee... It seems Skia does arcs differently –not connecting the lines between the arcs!

At least Quartz2D is doing it correctly! I'll push to askia_2024_dev branch. See if you can fix the Artist's Skia implementation of arc to follow W3C's behavior.

FYI: I have a fix for skia now.

[klytje]

FYI: I have a fix for skia now.

Ah cool! I gave it a quick glance this morning but realized I'd have to dedicate more time than I had to fix it :)

[djowel]

FYI: I have a fix for skia now.

Ah cool! I gave it a quick glance this morning but realized I'd have to dedicate more time than I had to fix it :)

Getting there...

LOL :-)

[djowel]

OK fixed. I'll merge to skia_2024

[djowel]

OK fixed. I'll merge to skia_2024

Merged

[djowel]

@klytje... Reopening, I think rounded_left is wrong:

If you zoom in, the right-top and right-bottom corners are not sharp. It is fixed by using .corner_radius(10, 0, 0, 10)

Or is it intentional? Assuming the default radius when not specified? It does not seem right, no?

[djowel]

#402