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


#1

PopupMenus now scale according to the AffineTransform and scaling factor of their target components.

Previously, PopupMenus would not scale if the GUI of the target component (or any of it’s parents) were scaled. The only way to scale PopupMenus was via the global scaling factor. This had several drawbacks as the global scaling factor would scale everything. This was especially problematic in plug-in editors.

Developers who have manually scaled their PopupMenus to fit the scaling factor of the target component will now have the scaling applied two times in a row.

You can either remove your manual scaling or disable this feature altogether by returning false in the shouldPopupMenuScaleWithTargetComponent Look&Feel method.


HiDPI and FLStudio
HiDPI and FLStudio
#2

#3

#4

#5

Thank you for this fix that will allow me to get rid of some custom workaround I implemented in my LookAndFeel subclass. However, I think the fix is currently not working for child menus. These currently appear to not scale like the parent menu which makes them unusable with the fix. Can you have a look?


#6

Thanks for pointing this out. Should be fixed on develop now.


#7

How should one handle the case where a menu is not attached to a child component, such as a TooltipWindow managed by a SharedResourcePointer (as per the class reference recommendation)?


#8

I think the scaling factor needs to be considered within MenuWindow::calculateWindowPos in juce_PopupMenu.cpp (parentArea and target). I found that a long popup menu fell off the bottom of the screen in high dpi modes (Windows) without this change.

Original:

void calculateWindowPos (Rectangle<int> target, const bool alignToRectangle)
{
    auto parentArea = getParentArea (target.getCentre());  

    if (parentComponent != nullptr)
        target = parentComponent->getLocalArea (nullptr, target).getIntersection (parentArea);

Suggested change:

void calculateWindowPos (Rectangle<int> target, const bool alignToRectangle)
{
    auto parentArea = getParentArea (target.getCentre()) / scaleFactor;  

    if (parentComponent != nullptr)
        target = parentComponent->getLocalArea (nullptr, target).getIntersection (parentArea) / scaleFactor;

#9

Shouldn’t it be the case for BubbleComponent as well ?


#10

@fabian Regarding BubbleComponent ?


#11

Bump :slight_smile:


#12

I don’t think this change makes sense for BubbleComponent. BubbleComponent is just a component like TextButton and it’s the user’s responsibility to add it to the desktop in a separate window if the user wishes to do this. Obviously, it’s up to you to scale any windows that you create appropriately.

However, I’ll fix the JUCE demo to do the right thing here.


#13

What’s the best way to handle TooltipWindow, I believe that attaches to the desktop so scales incorrectly in Windows for me when using high DPI plugins.


#14

You’ll need to scale any windows that you create manually (or use the global scaling factor) as they cannot pick up any parent’s scaler-factor or AffineTransform.


#16

Since TooltipWindow is a library component that we are given best practice for using, shouldn’t it be able to do that itself without me needing to override its behaviour?


#17

@Fabian I will gladly have a look to the Juce demo mods to see the best way to handle this.

Thanks !


#18

Sorry @hill_matthew. I didn’t see you were talking about TooltipWindow. Somehow this thread has gone from PopupMenus, to BubbleComponent, to TooltipWindow. I missed that last transition ;-).

Obviously, TooltipWindows should scale correctly. Can you start a new thread on exactly where you are seeing this bug?


#19

Sure, see here.


#20

@Fabian Same thing should apply for PopupDisplayComponent in Slider as well, no ?


#21

Nop ?