Huh? In what universe? The whole concept of grouping objects. - in any application - is to apply the group properties to EACH member… you can’t do that if you allow objects to belong in more than one group. Not to mention, we’ve only been talking the visibility property here… what happens to a group color, linetype, lineweight… or any yet to be determined group properties if you allowed an object to belong in more than one group? It would be a mess.
Simple. Don’t put point A in any group. Create a vest group, a cravat group, and a trouser group.
Exactly. Although I can definitely say it will be Red, as that’s what all basepoints are… on purpose.
I don’t see how. Each tool object has a boolean visibility member… when you toggle a group, it toggles the visibility member of each object. You could have 10 ways to do groups, but it still comes down to whether the object visibility is toggked on or off, and subsequently the associated qgraphicsitem that you see on screen. If one group way changes, it pulls the carpet out so to speak of any other way of grouping objects. That’s more or less what currently happens… as you have to toggle this, this, AND this, but NOT that, OR sometimes both, XOR sometimes neither.
On the other hand I could try and maintain the current behavior by including a preference to use “old style groups”, but I have no idea how that would work / look with all the other group properties I plan on adding? I suspect for example a tool would take on the props of the 1st group that is found that contains that tool object… or not. I seem to recall I previously added in my earlier fork a “groupId” element to each tool that was used when parsing a pattern file, that’s used to get a tool’s group properties.