SimpleSets: basic implementation

[Yvee1]

This PR implements the basis of SimpleSets.

Changes made to core and renderer:

• Added ExactWithSqrt and Rectangle (for iso rectangle 2) type aliases.
• Allow lambda functions that receive a renderer to be used as paintings.
• Add nextPage method to the ipe renderer, so that when called new added paintings are drawn on a new page
• Add Color constructor that takes a single integer. Intended to be used with hexadecimal literals, e.g. 0xffffff.

TODO:

• Work around CGAL bug: Arrangement insert throws bad_get CGAL/cgal#8468
• Handle edges of dilated patterns that overlap
• Smooth cutouts
• Fix code that draws shapes in a stacking order if possible, useful when wanting to import and/or modify the shapes later.
• Add proper Qt GUI?
• (Handle holes, I think this is only needed when allowing banks to bend more than 180 degrees in one direction, or when using patterns not created via the SimpleSets partitioning algorithm. So more of an extra.)

[Willem3141]

I think I don't grok the purpose of a FunctionPainting. One can already make an ad-hoc painting by subclassing GeometryPainting, for example:

    class SomePainting : public GeometryPainting {
        void paint(GeometryRenderer& renderer) const override {
            renderer.draw(/* whatever you want to draw */);
        }
    };
    IpeRenderer renderer(std::make_shared<SomePainting>());

I guess with FunctionPainting slightly less code is needed:

    IpeRenderer renderer(std::make_shared<FunctionPainting>([]() {
        renderer.draw(/* whatever you want to draw */);
    }));

but I'm not sure if the added complexity is worth it?

Anyway, did I miss a use case where using FunctionPainting would be significantly easier?

[Yvee1]

I would not use FunctionPainting on its own, but use the helper function (or the implicitly converting constructor that you suggest below).
Then you go from:

class SomePainting : public GeometryPainting {
    void paint(GeometryRenderer& renderer) const override {
        renderer.draw(/* whatever you want to draw */);
    }
};
renderer.addPainting(std::make_shared<SomePainting>());

to

renderer.addPainting([](GeometryRenderer& renderer) {
    renderer.draw(/* whatever you want to draw */);
});

I don't have a specific use case in mind that is way simpler this way, I added it only as a more concise way of drawing something simple. For me, having to create a class, derive from a specific other one, and override one specific method, in order to draw something is boiler plate and an obstacle when programming. Generally I would also define this painting class in a header, and have the implementation in the cpp file, though I see your point that you can also define it locally just in the cpp file. Part of the reason that I find this much simpler is probably that I'm more used to functional programming than object oriented programming.

[Yvee1]

An argument for adding this: a lambda function makes it easy to capture variables that are in scope. When debugging a function, I sometimes use IpeRenderer together with a lambda function to draw some debug info and save it to a file.

[Willem3141]

(see comment about FunctionPainting above) I'm also not a huge fan of having to do this in every renderer 🤔

[Willem3141]

To avoid this while keeping FunctionPainting we may provide an (implicitly converting) constructor from std::function<void(renderer::GeometryRenderer&)> to FunctionPainting?

[Yvee1]

I did not think of that.
That does mean you cannot do

renderer.addPainting([](GeometryRenderer& renderer) {
    renderer.draw(/* whatever you want to draw */);
});

because you need to still create a shared pointer, which I would like to avoid having to do.

[Yvee1]

We should at some point look into what helper functions can go into core.

I have some helpers for arrangements that can be useful in general: connected components of faces in an arrangement (in particular circulators for going over the outer and inner boundaries of the component); extracting a general polygon from a circulator.
Also for circle_segment_traits curves, polylines and polygons I have various helper functions, and a helper for computing the convex hull of disks.
Then there is a helper function for computing the intersection/difference between a (general) polyline and a (general) polygon.