X3msnake
commented
6 years ago The reason why simple satin is good is that you can change the width of the sating on the fly and see it reflected on the work. for newcomers that are bound to make mistakes this is a great thing since they can aproximate the desing as they go along without having to rebuild the shape.
Will you implement this versatility with the new satin? Or once you convert to satin you lose the editability of the thickness of the satin shape?
danielkschneider
lexelby
I personally don't use simple satin as I prefer to have the control that a satin column brings, and simple satin rendering of corners is suboptimal. It also doesn't support underlay at all.
On the other hand, I keep hearing over and over that others find simple satin much easier to work with and they prefer to use it when possible.
252 opens up an interesting possibility. If we can automatically generated a satin column for the user, why not do it transparently behind the scenes? We can eliminate the suboptimal simple satin algorithm entirely. When a plain path is encountered, convert it to a satin column internally and use that instead.
This opens up excellent possibilities. We can eliminate the distinction between simple satin and custom satin columns entirely. We can support underlay for plain paths. "E" stitch can be achieved simply by drawing a line, which will make applique super-easy. And finally, we'll stop confusing the user with these two kinds of satins, only one of which I actually like to write code for ;)
In order to do this, we need to implement #253 and #254. It's no good to present the user with random errors just because their path intersects itself. There's nothing wrong with self intersection -- it's perfectly legitimate for satin columns to run over themselves and I do it all the time.
Even if we do this, I'd still want to keep the Convert to Satin extension. That way, I can tweak the rungs as needed if Ink/Stitch doesn't place them optimally.