graphic points

[mwieder]

I submitted a pull request some six months ago to provide effective points for rectangles, rounded rectangles, and regular polygons.
I just corrected some code (the points weren't persistent after closing and reloading a stack).
The "effective" modifier is to make it clear that the points are read-only.
The pull request (rect_points) is now ready for code review.

This allows you to

Code: Select all

get the effective points of graphic 1 -- rectangle
get the effective points of graphic 2 -- rounded rectangle
get the effective points of graphic 3 -- regular polygon
set the points of graphic 4 to the effective points of graphic 3 -- place a freeform polygon into the space of a (e.g.) regular polygon

[mwieder]

pull request accepted, and I submitted another to provide points for ovals as well.

[malte]

Points for ovals sound awesome...

Thanks Mark!

[dunbarx]

I am glad to hear about the upcoming implementation of the "effective" points (as read only) of any graphic in the stable. But is it so onerous to enhance that property so that the points of any graphic can be set as well? Consider that one cannot, for example:

set the points of grc "regularPolygon" to the points of grc "lineGraphic". -- or vice versa

No error thrown, but no effect either. The points of the polygon are not merely empty, they do not seem to exist at all. But they are indeed empty, and not just missing:

answer the points of grc "regularPolygon" = empty --you get "true"

They have the property, but do not use it. In a way, this is an inconsistency in LC

But in the same spirit as, say, a table field being nothing more than a field with tabs, that is, one LC object class with different properties, a graphic ought as well to be a single object class, its variants distinguished in the same way, only by property differences.

I can see a need to be able to set the points of any graphic. For example, to create a regular hexagon. If you have the appropriate point list for such a thing, why should you be able to apply that only, say, to a line, rather than to a regular six sided polygon that you pulled from the tools palette?

Craig Newman

[mwieder]

Craig-

Yes, I thought long and hard about this. It *does* seem a bit weird not to be able to set the points of *some* graphics.
But the downside is that there's a lot of validation that would have to go on to set the points of regular polygons, including rectangles and rounded rects.

For the easy case, consider a rectangle... You'd have to ensure that there were only four points assigned, that they would need to be at proper vertices of a rectangle (90 degree angles and equal parallel sides)... the validation math gets worse if the rectangle is rotated off 0 degrees.

The math also gets even harder for regular polygons, even just for triangles. And I don't even want to think about validating round radius points.
And what should happen if the points can't be set because they fail validation? Should the script continue but not set the points? Should it throw a runtime error?

So that's why I left this at "effective points" or read-only points. If necessary, you can always set the points of a freeform polygon to a regular polygon's points and then fiddle with them afterwards - you'll end up with the same result.

[dunbarx]

Mark.

I understand that. And by the way, thanks also from me for your work in this.

But then what is the conceptual difference between a free-form polygon and a rectangle except for its name? In other words, if you can rotate a freeform by 1 degree and have the effective points adjust themselves, why cant a rectangle abrogate its default properties and join the fray?

As you say, the workaround is so easy, (just take a line and make it into a regular polygon with the requisite points) that why bother? Well and good. I was just wondering what separated and defined the two "subclasses" of graphics, sort of like a family split by an unwelcome marriage.

Now the polygon requires five points, not four, to "close" it. Is this a clue?

Craig

[mwieder]

But then what is the conceptual difference between a free-form polygon and a rectangle except for its name?

Yes, that's exactly my point. In fact, in the revRotatePoly bug report fix I submitted, I suggest changing the style of a rectangle to a polygon before setting its points. Unfortunately, you can't change the style back after setting the points, because the graphic automatically then takes on the dimensions of the enclosing rectangle.

http://quality.runrev.com/show_bug.cgi?id=12692

Now the polygon requires five points, not four, to "close" it.

True, but that's done automatically under the hood.

[bn]

@Craig,

actually
Rectangle, roundRectangle, Oval and Polygon graphics

behave differently enough from the user definable (via points)
Line, Freehand and freehand Polygon graphics

to merit a bit of consideration.

consider a Rectangle graphic that has a width of 100 and height of 100 points. You recreate that graphic by using a freehand Polygon and setting its points to
100,100
200,100
200,200
100,200
100,100

Those two graphics are only equal in appearance if the lineSize is set to 0.

As soon as you set the linesize to a value greater than zero width and height of the Rectangle stays the same (100 by 100) but the dimensions of the freehand Polygon increases dimensions depending on the linesize. In other words linesize grows inwards for Rectangle and outwards for freehand Polygon.

I guess that Mark in returning the effective points of a Rectangle graphic will use the dimensions of a Rectangle with linesize 0. To use the effective points of said Rectangle in a freehand Polygon assuming identical appearance of both graphics one would have to change the points the freehand Polygon or change width and height of the freehand Polygon as long as one uses a linesize > 0.

To show what I tried to explain above I made a stack that shows this.

Kind regards

Bernd

[[-hh]]

..........

[malte]

Hi all.

this is my opinion:
There should be only *one* type of grc: Polygon. Every other grc type (special types of polygons) is easily derived from this.

I beg to differ. If only one type, then please let it be a bezier object...

Best,

Malte