I tried to study the relational problems between the existing group concept and the potential new CPlaneGroup concept in the following “conceptual class” diagram (the existing class inheritance hierarchy I have no knowledge about, of course).
By drawing the diagram I realized that backwards compatibility is at risk if not only adding the functionality of the concept of “Implicit Planes” instead of trying to replace the current membership.
Fig.1. A pseudo-class diagram demonstrating the component relationships with existing groups and wannabe CPlaneGroups :
In the current concept, depicted as the role “explicitMemberOf” of a group including its multiplicity, is depicted in the upper left corner, Gh Components can “explictly” belong to none or to many groups (0…1). Explicit means here that the user have to explicitly add a component to a Group.
I would love to see a CPlaneGroup trapping its components implicitly if a component is located within the area of the group. But even if skipping this way of “becoming-a-member”-idea in the Plane concept, (staying only with the old explicit membership), there is still the concept of components being implicitly affected by the Plane aspect (apart from becoming members, that is).
And this aspect of implicitly inheriting the CPlaneGroup’s Plane can’t be a many-relation on par with the group membership(s). Instead it has to be limited to one (1) implicit Plane per CPlaneGroup and Component. This limited multiplicity (“1…n” instead of “n…n”) is depicted with the other link called “ImplicitPlaneInfo”, with the role name “implicitPlane” (located below the GhComponent class).
CPlaneGroups and its Components may share the transformation of a common ImplicitPlane, but CPlaneGroups being members of another CPlaneGroup have their own relation (via the role “affectedGroups”) See Fig.1.
I fear the situation in which a component, or CPlaneGroup appears to be members while not actually being attached to the CPlaneGroup, thus deceiving the user into thinking that any Plane manipulations actually affects the component or subgroup (because that would be a serious logical bug). It is for this reason I was thinking in terms of implicit membership (by its location withing the framed area of a group).
But “implicit membership” doesn’t play well with the current concept of explicitly assigned group membership, so the logical-bug-risk-problem perhaps should be addressed by other means. One solution would be if each component have a symbol indicating which group it is member of.
A solution for group-membership could start from the level of the Group itself. Each Group could have a Z-order indicator in the upper left corner (the z-order number from 0…+) and each member group on the next z-level would have the indicator saying 1:0 and 1:1 for the second group on the same first z-level. A group within one of those groups would be labeled 2:0 , meaning the first (0) group on the third (2) z-level. A level-n component inside the area of a group with the level<>n (not the same level number) would be flashing in red, meaning, “isn’t something wrong here?” (yes, the component or group isn’t assigned, or it’s on the wrong z-level). And so on.
In any case, the logical-bug-problem must be addressed since it’s much more serious than in the current version where non-assigned components, while visibly within the area of a group, only causes annoyance when trying to move the group (which btw also should be fixed, in my opinion).
MULTIPLE MEMBERSHIP CONFLICTS
For now I have no good idea about how to handle the compatibility problem of (current) groups and components being part of multiple groups. Perhaps it simply should not be allowed - under certain conditions. The compatibility problem could be reduced if the rule of “One Implicit Plane Only” (implies membership of only one CPlaneGroup as well) is enforced when, and only when, a CPlaneGroup has its Plane capability switched on, but not when its switched off (default).
And when the user attempts to switch on the property “CPlaneEnabled” (off by default), then the conflicting items could start flashing, prompting for the user to resolve the conflict.
In 100 out of 100 version upgrades from Gh1 to Gh2 this would work without hassle, simply because no one has ever designed Gh defs using CPlaneGroups before, so only the component layout would have to change a little bit if introducing this concept into an old Gh definition.
WORLD IS A CANVAS
Or, was it the other way around? Anyway, the Gh Canvas should be perceived as a CPlaneGroup as well, defaulting to World. Anything on top of it, or “within” it is implicitly affected by its Plane. The Canvas only has no in-port and out-port.
So while we do not think of it, any components on the Gh Canvas actually has an “implict Plane” already now, because they think they reside in World, although no one knows why and how… (the blessings of zeros may play a role here). Anyway, for the above reason I let the Canvas inherit from CPlaneGroup in the diagram, meaning that Components always belong to at least one CPlaneGroup (the World Canvas). Therefore a component’s basic behavior doesn’t actually change if being placed inside another CPlaneGroup, it’s just being affected by a different transformation.