Implementing Z-order in schematic editor - issue 11934

[Kuba Sunderland-Ober]

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

[Seth Hillbrand]

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

Seth Hillbrand

Lead Developer

+1-530-302-5483‬

Long Beach, CA

www.kipro-pcb.com    in...@kipro-pcb.com

--
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+u...@kicad.org.
To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/6ad5cbc4-dacb-4286-8cef-e2692aa2eaf5n%40kicad.org.

[Mark Roszko]

What's the use case for messing with z-order? 

To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-qcmW%3Dx9P61yUHzvVo20W9oNWDnyJk5YAPnqNJ%2BiWyK9A%40mail.gmail.com.

[Kuba Sunderland-Ober]

My particular use case is: schematics where a lot of chips are on a bus, but for clarity the bus is a bunch of individual wires. Think retrocomputing - a bunch of DRAMs sitting on a common address bus. These were fairly common back in the day. The bus wires go under the chips. Another common case for me is to draw more complex symbols where filled shapes have to overlap and hide other stuff.

The floating-point Z-order is a good idea I think.

I will work on a spec.

> 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.

The layers are the graphics display implementation detail, am I understanding that correctly?

- Kuba

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.