DrawableComposite resets coordinates when inserting DrawableImage

General JUCE discussion
1

Hi I have a DrawableComposite placed at a non-zero coordinate. When addAndMakeVisible() a DrawableImage wrapped into another DrawableComposite it will reset its own coordinates to (0,0)?

auto root= new DrawableComposite ();
root->addVariousDrawabables ();
std::clog<< root->getX()<<":"<<root->getX()<<std::endl;
//output: somewhereX: somewhereY

auto intermediate= new DrawableComposite ();
intermediate->setBounds (somewhereelse)
auto image= new juce::DrawableImage();
image->setImage (something);
intermediate->addAndMakeVisible(image);

std::clog<< intermediate->getX()<<":"<<intermediate->getX()<<std::endl;
//output: somewhereelseX: somewhereelseY

root->addAndMakeVisible(intermediate)
std::clog<< root->getX()<<":"<<root->getX()<<std::endl;
//output: 0:0

std::clog<< intermediate->getX()<<":"<<intermediate->getX()<<std::endl;
//output: 0:0

How is this suppose to work?

2

Unfortunately I don’t know the answer, but if you’re working with SVGs I had a bunch of headaches recently involving unexpected and confusing (but consistent) results involving boundaries and origins. So I feel your pain…

3

Yes, thats what its coming from. The positions are defined by svg elements. Some of the svg elements need to be replaced with rendered images.
The drawable interface seems so arbitrary behaving that its nearly impossible to describe whats happening. Its just pure luck if the parsed elements appear near an estimated position. And then adding a certain element and all moves around again. What a time waster!

However what has been encountered above is independently reproducible without any svg reference.

4

This is why I’d really like to replace Drawables with some objects that aren’t Components… the confusing thing about them is that for them to work, you have to ignore their bounds.

Getting the bounds is meaningless, and setting them will break the way these classes work - each Drawable class has methods positioning its content that’s appropriate for that type, and then the class itself will re-position its own bounds to make sure it covers the area it needs to display its content. As a user, you just need to ignore ALL of the Component methods (apart form maybe adding it to a parent!) and things might start to make more sense.

5

Thanks jules,
that does not need further commenting.
So how do I solve the above? I am actually pretty fine ignoring whatever needs to be ignored, however how do I positioning the above and preventing jumping all over me?

6

Well, there’s a method DrawableImage::setBoundingBox() which you need to call to tell it where you want the image.

7

mhhh, no, it moves it differently, but not where it needs to go.
Could you please outline how I could position the image?

Following does not seem to work correctly:

image->setBoundingBox (
	juce::Rectangle<float>(
		bounds.getX(), bounds.getY(), bounds.getWidth(), bounds.getHeight()));
8

Do you set it after giving it the image?

9

Yes.

10

Can you give us a better bug report than saying it’s “not where it needs to go”?

e.g. some code that someone else could try that would demonstrate it?

11

… mhhh, what more of an example would you want?
Anyway I found a workaround: to use intermittent Components instead of DrawableComposites. But now, the root Component does not receive mouse events anymore as soon as I addAndMakeVisible() another Component containing a DrawableImage…!?