That’s kinda of what I did… but again none are the same as the line colors
[
Well… there’s a solution to that… I can set the max number of items so there is no scroll bar.
Since in this case the support colors don’t have to deal with the schema, not much to keep to track of. 
It was an impulsive question. A MACRO capability is one which performs a predetermined set of instructions. It would likely be too time consuming to attempt to code this with a platform like QT that is event driven (by user actions).
I get that… I’m not sure how that would apply to adding other colors to the combobox for the support (hilight) colors.
It would be kinda of like having a MACRO within the tool.
I was responding to this statement. I have used other tools that actually have a MACRO capability and it can be handy, though I realize you were not offering to implement a true macro capability
Solved the discrepancy between the rotated objects and the (magenta) highlighted visuals. They both line up now… as opposed to the original post pic. 
I’m now resolving the same sort of alignment issue when selecting a different origin point. And it just occured to me I need to test what happens with an existing older schema pattern that has move tools in it… may have to add some conversion stuff to set the origin point to NULL, and the rotation angle to zero - as if there is no rotate.
Ok… here’s what I got so far… just want to tweak some of the Z values which determine the “layer” if you will of the points and lines.
Option 1: Selecting a group and items and moving the center point (source origin) of the group to a new rotation origin, then rotate the group.
Option 2: Selecting a group of items, select a source origin point NOT part of the group, move the source origin point to a new rotation origin, then rotate the group.
Option 3: Selecting a group of items, select a source origin point that is part of the group, move the source origin point to a new rotation origin, then rotate the group.
I’m going to leave this tool at that.
That being said, I now have a good idea how to implement Grace’s idea of creating a draft mode Union tool… which will be more or less selecting a group of items, select a point in the group, and “Snap” it to another destination point (Not in the group?)… also allowing one to rotate AND / OR flip the destination group around the snapped destination point. Could possibly add a 3rd point to establish the rotation angle without having to explicitly define a line angle in the rotation formula. We’ll see.
Reimplemented the arrowed line from the Triangle tool to apply to the Move line. Also got the rotation origin to appear on top of the move line.
That’s wonderful But if we can move & rotate groups of items, I think it should be already working like a union tool, don’t you think? So would another tool be necessary?
I think pattern piece rotate option will be nice in the Piece mode, though… just something ‘simple’ like with the labels that one can grab a corner and rotate a whole piece around a centre swivel point??? But that can be for a later date. Really not important. 
Not really… because you’re not matching a point within the source group to some other destination point. Also IMO to be useful as a union tool you need to be able to flip the destination group… something you can’t do with the piece Union tool. Yes, there are probably work arounds, but it seems it would be easier automate the [flip] union within one tool.
Certainly doable. Without getting too deep into the weeds… every thing you see on any of the screen - or boards as you call them - are QGraphicItems of one sort or another. Some items being a string of items with a parent- child-[child] relationship… like the point name labels. The Labels and Grainlines being custom QGraphicsItem that happen to have the resize box and ability to move and rotate - with the pattern piece graphic item as the parent. There’s no reason why we couldn’t add the same (resizing and?) rotation to the pattern pieces… they already move.
Ok, thank you, but I don’t think the (resizing) will be a good idea.
Yeah… I just threw that out there… in the context of the Piece mode wouldn’t make much sense.
I assume you would want to be able to rotate pieces so as to avoid the Layout mode?
Yes…
I’ve come to enjoy doing my own layouts. It takes a wee bit longer but I don’t only save paper & ink but also time in gluing everything together. 
Unless I can come up with an easy solution, I may have to revert the “arrowed” move line back to just a plain line.
In a nutshell… the plain line uses a QGraphicsLineItem, where you can get and set the line length - which is crucial to this visual, but not to the triangle tool. The arrowed line uses a QGraphicsPathItem, where you can get the length of a path, but you can’t set it - no beuno.
Maybe I can child an arrow path item from the line item? Widgets are like that… when you paint a parent widget, any children widgets are also painted. We shall see.
Perhaps we’re looking in the wrong place to fix that arrow. Perhaps one should look at why that arrow is necessary in the Details. Surely there should be a way to accept a curve into a pattern correctly without it needing to be reversed? I mean, when you’re selecting a path from on place to the next, it should read a curve from where it is coming from to where it is going to and not according to how it was initially drawn.
Ek sê net (just saying).
No… no. This has nothing to do with the curve arrows - different class method. This is simply a straight line showing which direction the axis is going in the Triangle tool… since it was already there I figured I’d use it in the Move tool to show which direction the objects were moving. It’s not really needed, but if I can figure it out it’s another Qt building block in my… ahem - tool belt. Besides, I might be able to use it elsewhere down the line.
Aaaahhh… ok. Why do I always get the wrong end? Ok, sounds good to me 
I can understand the confusion. In fact I’m going to check the code that creates the arrows for the curves - which I assume might duplicate some code (which RT tended to do) - and see if I can reduce some of it - or not.
Figured it out… got an “arrowed” line (red box) to work correctly in the
Move tool:
and in the 
Triangle tool:
