A user recently reported they were relying on the z-index support removed in 0.1.7. If I remember right, I did this because work on inherited transforms was changing the way the Qt scene object graph was organized, and maintaining Z-index semantics was tricky, and unlikely to work in a backwards compatible manner.
Since there are real use-cases for this feature, this decision is worth revisiting. I think z-index support probably could be reimplemented, using or not using Qt's z-index system. Not using it would be a matter of changing the child object render order in PositionedObject.render from a simple list iteration to a pretty simple 'group by z index, then iterate' process. Alternatively, there probably is a way to use Qt's z-index system, but some care would be needed since the scene graph structure changes when objects are in or outside of flowable contexts.
A user recently reported they were relying on the z-index support removed in 0.1.7. If I remember right, I did this because work on inherited transforms was changing the way the Qt scene object graph was organized, and maintaining Z-index semantics was tricky, and unlikely to work in a backwards compatible manner.
Since there are real use-cases for this feature, this decision is worth revisiting. I think z-index support probably could be reimplemented, using or not using Qt's z-index system. Not using it would be a matter of changing the child object render order in
PositionedObject.renderfrom a simple list iteration to a pretty simple 'group by z index, then iterate' process. Alternatively, there probably is a way to use Qt's z-index system, but some care would be needed since the scene graph structure changes when objects are in or outside of flowable contexts.