Breaking Change: PopupMenus now scale according to the AffineTransform and scaling factor of their target components

@Fabian @jules in Slider, PopupDisplayComponent uses BubbleComponent to display a tooltip.
By default the parentForPopupDisplay is nullptr hence the popup is on the desktop which means that it won’t follow the app own scale.
Should’nt the implementation take care of this like you guys did for PopupMenu ?

Thanks !

Sorry for the long delay. I think this is now fixed on develop with commit 8377a64.

@Fabien not yet. It looks there is still an issue with the width/height. Probably the return of getContentSize in BubbleComponent. The arrow of the bubble component looks offseted as well.
By the way, you should probably only display the popup display when isEnabled() of the sliders returns true ?

What exactly are you returning in getContentSize? I’m testing this using the ComponentTransformsDemo in the DemoRunner. I did a find&replace for s->setPopupDisplayEnabled (true, false, this); -> s->setPopupDisplayEnabled (true, false, nullptr); in WidgetsDemo.h to ensure that the popups are always real desktop windows. I then run the ComponentTransformsDemo.

Also scaling the width and height ends up double scaling the bounds for me.

Not returning anything myself. Just what juce::Slider own impl of PopupDisplayComponent is returning
void getContentSize (int& w, int& h) override
{
w = font.getStringWidth (text) + 18;
h = (int) (font.getHeight() * 1.6f);
}

Just did the exact same test you did.
Am I missing something ?

Ahhhh Windows. Let me test it there…

By the way, the addToDesktop flags should probably feature as well the following flags
| ComponentPeer::windowIgnoresKeyPresses
| ComponentPeer::windowIgnoresMouseClicks
like the tooltip implementation.

So far I was using a custom implementation of a similar feature in my sliders and trying to backport to juce own version because of those scaling fixes :slight_smile:

Sorry for getting back to you only now. The root cause of the issue had nothing to do with the Slider or the BubbleComponent. It was a bug in ComponentPeer and affected any top-level component with a scaling transform: the scaling transform would always be applied twice. I’ve now fixed this bug on develop with commit 3e327a5.

I’ve also fixed another bug in BubbleComponent which didn’t take the transform of the BubbleComponent into account when figuring out where there is space on the screen to place the BubbleComponent. This is now also fixed on develop with commit b85726a.

And finally, commit 9fee13b (also on develop) adds the ComponentPeer flags that you requested above.

Let me know if this works for you!

3 Likes

Looks good.

Thanks !

Would be great if CallOutBox::launchAsynchronously could refers to a component to which it point to so it could use this one to do the same getApproximateScaleFactorForComponent when calloutbox is on the desktop

Thanks !

Bump.

If I add it afterwards, it doesn’t work

 juce::CallOutBox& myBox = juce::CallOutBox::launchAsynchronously(pChildComp, screenBounds, nullptr);
        myBox.setTransform(juce::AffineTransform::scale(2.f));

so I cannot even fix it manually as I supposed it’s not possible once the CallOutbox is created.
Quite annoying.

Is it possible to have a popumenu apply a scale factor based on it’s parent component, but display under the mouse like it’s default functionality when not attaching to a specific component?

1 Like