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

On Mon, May 5, 2025 at 4:43 PM 'Seth Hillbrand' via KiCad Developers <
[email protected]> 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    [email protected]
>
>
> On Mon, May 5, 2025 at 4:23 AM 'Kuba Sunderland-Ober' via KiCad Developers
> <[email protected]> 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 [email protected].
>> 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 [email protected].
> 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 [email protected].
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.

Reply via email to