JUCE lets you define the z-order of child components as an optional second argument to
addAndMakeVisible, which is nice. However, I find the way it works quite odd and not how I think z-order should work (please correct me if I’m wrong).
In particular, if a component has N children, then all z-indices >= N will be considered equivalent, because of this code in
if (zOrder < 0 || zOrder > childComponentList.size()) zOrder = childComponentList.size();
The surprising consequence is that if you have three children A, B, C, which you add in this order, with z-index 0, 2, 1, respectively, it means something different than if you use 1, 3, 2 instead. In the former case, B will be the top-most component (as expected). However, in the latter case, surprisingly the top-most component is C, even though B has the higher z-index.
By the same token, negative z-indices are meaningless in JUCE, which I find equally surprising.
I believe that the expected behaviour is that components will always be correctly sorted by their z-indices, with higher indices meaning more in front, and that any integer is a valid z-index.
Dear JUCE team, could you please fix this? Or alternatively, tell me why the current behaviour is the expected one?
P.S. @jules, I see what you did there, but… what do you think about this: not to use the
zIndex to index into
juce::Component::childComponentList, but instead store it explicitly alongside the child component, and use its values (which can then be arbitrary) to maintain the order of the array? Basically, make
childComponentList something similar to a
zOrder as the key?