Re https://gitlab.com/kicad/code/kicad/-/issues/11934
I'd like to work on this. Here are my initial thoughts. - Enforcing specific non-default Z order on everything drawn is excessive. The "default" order works for 99.99% of cases. I don't want to pollute every drawn primitive with a global Z numerical order that is dumped to the .kicad_sch file, causes diff noise, and so on. - Instead, I propose relative Z order, with 3 possible options at the .kicad_sch level: Default, Above <Entity>, Below <Entity>, where the entity is a reference to another thing within the library symbol or within the schematic sheet. - On file format upgrade, all primitives get the Default Z Order, and this default value is not saved to the file. Only the non-default values get saved. The "Default" Z-order can be called Unstacked for technical discussion. The non-default Z-order can be called Stacked. In terms of behavior, unstacked entities behave as they currently do. Stacked entities belong to exactly one Stack (out of possibly many). The stacks are behaviorally linked lists. Within a symbol or sheet there can be several stacks, since stacking is relative, and not everything that's stacked has to be stacked relative to entities in the same stack. The stacks are internal to a sheet or symbol and don't cross those boundaries. New actions: - Unstacked entities: Raise Above... and Lower Below... where the user has to select another entity that the order is relative to. This stacks the first entity and puts it into the tree list includes the clicked (second) entity, in proper order. - Stacked entities: Raise Above... and Lower Below... gain a new behavior. If the relative-to entity is in the same stack, the action entity remains in the same stack, moving to the desired position. If the relative-to entity is unstacked or in a different stack, the action entity gets moved to that stack. - Stacked entities: Raise, Lower and Default Z order. This moves the entity up and down in the stack, and unstacks it, respectively. These actions work on either single entities, or selections. A selection is treated like a single entity, so several primitives can be re-stacked above/below an unrelated entity. Thus they can be moved between stacks. KiCad has technical users, so there is some tension between hiding the stack nomenclature and exposing it in a way that makes the less obvious aspects of behavior discoverable. This will need prototyping to get a feel for what's most natural. In the UI, the stacks could be called "Z Stack" or "Z List". If the concept is exposed, then we can also have a "Select Z Stack" action, which selects all entities within the stack, "Highlight Z Stacks" which highlights all entities that are stacked, with perhaps a rats-line (like ratsnest, but linear not tree-like) sneaking through the origins of all entities in each stack to visualize what's in which stack. After/during the requisite discussion, as I work on the prototype, I'm sure changes will be made based on user feedback from the nightlies, etc. Any feedback/discussion is hereby encouraged. Cheers, Kuba Sunderland-Ober -- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/6ad5cbc4-dacb-4286-8cef-e2692aa2eaf5n%40kicad.org.
