What's the use case for messing with z-order? On Mon, May 5, 2025 at 4:43 PM 'Seth Hillbrand' via KiCad Developers < devlist@kicad.org> wrote:
> Hi Kuba- > > It would be good to capture this into a single document for discussion. > We usually employ Google Docs > > My 2-cents: If you are going to implement z-ordering, please use the > standard model where everything is stacked and you can raise/lower/bring to > front/send to back. Creating a new paradigm where things are either > default or relative will be confusing to users. > > Instead, I would suggest that you utilize a floating point z order. > Elements currently have x/y coordinates. You can introduce a z > coordinate. Moving an element up will change its z value to half-way > between the object on top of it and the next highest object. This way, the > order change only affects the element being moved. > > We will need to define how we want elements to move. Currently, we draw > elements of the same type on the same layer and the layers are stacked. If > you implement full z-ordering, this will require some re-thinking about how > elements are added to layers. You may need a dynamic number of layers for > drawing based on the ordering. > > But this will require a full specification document as the changes here > will likely be more complicated and deeper into the KiCad guts. > > Seth > > > [image: KiCad Services Corporation Logo] > Seth Hillbrand > *Lead Developer* > +1-530-302-5483 > Long Beach, CA > www.kipro-pcb.com i...@kipro-pcb.com > > > On Mon, May 5, 2025 at 4:23 AM 'Kuba Sunderland-Ober' via KiCad Developers > <devlist@kicad.org> wrote: > >> 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 devlist+unsubscr...@kicad.org. >> To view this discussion visit >> https://groups.google.com/a/kicad.org/d/msgid/devlist/6ad5cbc4-dacb-4286-8cef-e2692aa2eaf5n%40kicad.org >> <https://groups.google.com/a/kicad.org/d/msgid/devlist/6ad5cbc4-dacb-4286-8cef-e2692aa2eaf5n%40kicad.org?utm_medium=email&utm_source=footer> >> . >> > -- > 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 devlist+unsubscr...@kicad.org. > To view this discussion visit > https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-qcmW%3Dx9P61yUHzvVo20W9oNWDnyJk5YAPnqNJ%2BiWyK9A%40mail.gmail.com > <https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-qcmW%3Dx9P61yUHzvVo20W9oNWDnyJk5YAPnqNJ%2BiWyK9A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 devlist+unsubscr...@kicad.org. To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CAJjB1qL%2B_%2Bvg4V-pYGXOABpCFXsK3e%2B%3DS123_bRdB16tSpyDqA%40mail.gmail.com.
