It all started with a CallOutBox not displaying its arrow when it still seemed possible for it to.
Now I have a test application, where I can freely move a target Label inside a parent Component, and after every movement a CallOut that points to the target label gets updated.
The strange behavior happens in the corner (thus the pun in the title), see the attached video:
- In a certain position (at the start of the video), the callout arrow is there.
- I move the target label 1 px down (I trigger movements with arrow keys): the arrow disappears while it still has room to be visible. The available room did not change, just the position. This is problem “a”.
- I move the target label back 1 px up: the callout arrow does not reappear, despite the target position being the same of point #1 when the arrow was present.
This is problem “b”: whether the arrow is displayed or not, does not depend only on the current relative positions of available and target area, but also from the past “history” of the callout. It has “memory” and, in this sense, is non-deterministic.
This result has been observed with latest JUCE 8, current JUCE 9 preview and latest JUCE 7 commit.
I have tried to make some sense of the logic used by CallOutBox to determine its position, but even with the help of an LLM it remains obscure to me and I have no more time to investigate this issue.
To replicate the result see the attached the PluginEditor.h and .cpp files of the UI (for simplicity, I have edited an existing empty plug-in project I had around).
Is it possible to update CallOutBox so that it is positioned deterministically, only based on the available and target bounds, and that its arrow remains visible when there is enough room for it without inexplicably disappearing?
PluginEditor.zip (2.6 KB)