Update dimradial draw function

[bhattigurjot]

No description provided.

[dxli]

Trying to cleanup a little bit here, so the code reads easier:

    using namespace lc::geo;

    Coordinate offsetX{te.width + capSize, 0};
    Coordinate offsetY{0, te.width/4 + capSize/2};

    if (textisInside && textFitsInside) {
    auto const offset = (definitionPoint2().x() > mousePos.x()) ? - offsetX : offsetX;
    auto const tLinePos = mousePos + offset;
    auto const tMText = mousePos + offset/2;

    if  (definitionPoint2().y() > mousePos.y()) {
        tMText -= offsetY;
    }

    //the painter code might read better with some adaptive interface
    auto move_to = [&painter] (Coordinate const& coord) {painter.move_to(coord.x, coord.y);}
    auto line_to = [&painter] (Coordinate const& coord) {painter.line_to(coord.x, coord.y);}

        move_to(definitionPoint2());
        line_to(mousePos);

the logic can be further simplified as far as the intention is still clear enough to be read from code.

[rvt]

dli,

perhaps we can create some header for that adaptive interface with some generic (wildly guessing).
I wanted to keep our entities (Coordinate etc... etc) out of the painter functions so we don't have potential circular references, or at a minimum that the painter doesn't depend on the geo classes. This is why I didn't add the Coordinate classes as method paramaters.

[dxli]

I agree.

mixing geometry/logic and dependency of painter interface seems to be bad.

[bhattigurjot]

Do you want me to make such changes?

[dxli]

@bhattigurjot
please make your own judgement call, and avoid getting into the "deadlock" situation, as I explained early on: while one party is waiting for comments, and the other party is waiting to see actions.

Thanks!