Use font and size from DAW in juce popup menus?

Hello

I have a problem that a juce vst plugin have very small popup menu size on a 4k monitor and do not use the font and scaling windows use and the DAW use.

which code need add that the juce based plugin use for all popup menus the windows system font and windows system scaling setting (175%) ?

How are you creating the PopupMenu? If you’re using a ComboBox or Menu, this should work automatically. Otherwise, if you’re creating a PopupMenu and displaying it directly, you should use PopupMenu::callMenuAsync to display the menu, and pass Options{}.withTargetComponent (childComponentOfEditor) as the argument. The popup menu will query the effective scale of the target component and then set its own scale accordingly. If you use a child component of the plugin editor as the target component, the popup menu should be scaled correctly.

1 Like

Hello

the program i have not program and no source code. i only want unify use on studio one in win 64 good. i give your information to the developer of unify. and he tell he find no easy solution and search long for it. he suggest me to do the example that work well with AudioPluginHost that is in juce sdk.

maybe somebody of juce developer can enhance the example that it offer a popup menu and in this popup menu can open a about window. The about window and the popup menu should use same font as the main window. is this easy possible ?. see screenshot what happen in unify . also the popup menu are very small. I use in my windows as scale factor 175%. and the main window of unify is scale correct to 175%. popup menu and child windows not.

please help and i think such a example also help other juce programmers for good 4k support.

see here, on which place i change the scaling of windows.

In the case of popup menus, the PopupMenu will be drawn at the same scale as the targetComponent member of the Options passed to showMenuAsync. To display the menu at the correct scale while using a custom position, you can do something like:

menu.showMenuAsync (PopupMenu::Options{}.withTargetComponent (button)
                                        .withTargetScreenArea (Rectangle<int>{}.withPosition (Desktop::getMousePosition())));

For the about window, the simplest solution is probably to override Component::getDesktopScaleFactor() so that it returns the same scale factor as the plugin editor. This will probably require passing the scale factor (or the editor component itself) into the constructor of the temporary window.

For an example of this working in practice, you can look at the TooltipWindow class in JUCE. The tooltip window is drawn at the same scale as the component it is hovering over using this technique.

Hopefully there’s enough there for the plugin developer to make some progress.

1 Like

I’m the author of Unify, which is a plug-in that hosts other plug-ins. I’m already using the getDesktopScaleFactor() override trick for the main window and other windows over which I have full control. The big problem arises when we need to open the GUI of a hosted plug-in in a separate window; I’ve never yet been able to figure out how to scale those somehow. If anyone has any suggestions, I’d be most interested.

I am happy enough when popup menu in unify and unify plugin inside unify over which you have control and source(for example midi box and all other) scale correct to 175%. i read somewhere it is not possible easy to scale a plugin that is not written for scaling(what reaper or other do with non 4k able plugins(kontakt) is only a hack to get it working). but this most not need. i have most plugins that work in 4k ok, so i need no scaling for non 4k able plugins.

@calvin
Thank you for clarifying, but let’s continue this discussion on the Unify forum.

I just tried putting together a plugin which hosts and displays an inner plugin editor. On Windows, it looks like the inner editor is automatically drawn at the correct scale, accounting for the scale factor of the display, and is re-scaled when dragging the editor between monitors.

Creating a secondary window to hold the editor is less successful. The embedded editor still displays at the correct size/scale, but the other contents of the window (including the window border/decorations) are not scaled at all.

Is this the same issue that you see, or do you see something different? I’d like to make sure we’re talking about the same issue before I start looking for solutions.

@reuk:

Thank you so much for taking an interest in this. I have also created a test project, which I would prefer to use as the reference code for this discussion: https://github.com/getdunne/juce-plugin-wrapper.

  • In the createEditor(), there is an #if to determine whether the hosted plug-in’s GUI is used directly as the wrapper plug-in’s editor, or created in a separate window.
  • There is also some very simple code to present a popup menu and About box
  • If I compile this as a stand-alone app, the wrapper plug-in’s GUI, the popup menu and About box all respect the monitor scale factor set in Windows (Win10), but the hosted plug-in GUI (created in a separate window) remains at 100%.
  • If I compile as a VST3 and host in Reaper (latest version), the wrapper plug-in’s GUI respects the monitor scale factor, but nothing else does.
  • If I host the VST3 in the JUCE AudioPluginHost, everything respects the monitor scale factor

My test project models the relevant aspects of how Unify handles hosted plug-ins, popup menus, and About box, so whatever is needed to make it behave properly will probably work for Unify also.

Unify has one other aspect which the test project does not include: a user setting to specify a GUI magnification-factor (defaults to 1.0) which is supposed to act as a multiplier on the desktop scale factor. This also has problems, but let’s worry about those later.

I’m very, very happy to get this discussion started, and I very much hope it may yield answers to even some of the issues. It would make a huge difference to many of our customers.

2 Likes

It would be nice if you could create a shortcut for this since it’s something that’s done pretty much for every menu.

Something like:

menu.showMenuAsync (PopupMenu::Options{}.withTargetComponent (button).atMousePosition());

I want this juce-plugin-wrapper from @getdunne compile but i get a message from projuce “incompatible License and Splash screen settings” what can do ?

EDIT: when i change splash sreen settings i can compile.

I am able to compile and run the example that is simular what need with visual c 2019 community. i test MDIdemo.h

it open all windows with correct size on 4k screen.

it open main window with this code
DocumentWindow (name, juce::desktop::getInstance().getDefaultLookAndFeel()
.findColour (ResizableWindow::backgroundColourId)…

and shane plugin wrapper open main window with this code

PluginWindow::PluginWindow(AudioProcessor* thePlugin)
: DocumentWindow(thePlugin->getName(), Colours::lightgrey, TitleBarButtons::closeButton)
, plugin(thePlugin)

and seem transfer look and feel automatic to child windows

maybe compile mdi example as a VST plugin and look if it work too. if not then maybe juce can change ?

but i need admit that i only have few time look on juce

@calvin I forgot to set the “Display the JUCE Splash Screen” item in the Projucer to “Enabled”. I have done this, and pushed the change to GitHub.
image

do you use visual c 2019 for windows ?. I use this and projuce 6.1.0 also before i can compile i need deactivate some not important functions because i get compile errors “hat keinen member” mean no member.

Schweregrad Code Beschreibung Projekt Datei Zeile UnterdrĂĽckungszustand
Fehler C2039 browseForFileToOpen ist kein Member von juce::FileChooser. PluginWrapper_SharedCode H:\juce\juce-plugin-wrapper-main\Source\WrapperProcessor.cpp 174
Fehler (aktiv) E0135 class juce::FileChooser hat keinen Member browseForFileToOpen. PluginWrapper_SharedCode H:\juce\juce-plugin-wrapper-main\Source\WrapperProcessor.cpp 174
Fehler C2039 show ist kein Member von juce::PopupMenu. PluginWrapper_SharedCode H:\juce\juce-plugin-wrapper-main\Source\WrapperEditor.cpp 67
Fehler C2039 browseForFileToSave ist kein Member von juce::FileChooser. PluginWrapper_SharedCode H:\juce\juce-plugin-wrapper-main\Source\WrapperProcessor.cpp 160
Fehler (aktiv) E0135 class juce::FileChooser hat keinen Member browseForFileToSave. PluginWrapper_SharedCode H:\juce\juce-plugin-wrapper-main\Source\WrapperProcessor.cpp 160

I have remove the code which cause the error to compile. i can compile now and vst file is create and i move to VST 3 folder. but there open no window on studio one and reaper crash with the vst3.

the problem i see in the juce examples there is code that is usefull for GUI and multiwindow. But the plugin examples contain no example that open another window and code is diffrent to GUI examples. so can not easy switch the gui examples to work as plugins. the plugin examples call no method getDefaultLookAndFeel

i think it is good when a juce expert can do the mdiDemo as a plugin, and it help also other users.

@calvin From the README.md in my GitHub repo:

This code was developed using JUCE version 6.0.7.

I’m not able to update this for JUCE 6.1 right now. I’m incredibly busy working on something else. You can get earlier versions of JUCE from Releases · juce-framework/JUCE · GitHub.

I know you’re trying to help, but I’m waiting for an answer from @reuk of the JUCE development team. Please let the actual JUCE experts deal with this.

ok, but then you need tell before that this not compile on newest juce. good that i try it so it is know that it can compile only on 6.0.7 and reuk can save time, visual C 2019 you use too ?

@reuk If you’d prefer me to update my test code for JUCE 6.1, or if you’d prefer to use your test code instead for context, just let me know. I’m sure you’re just as inundated with support requests as I am, and I’m happy to do whatever I can to avoid making your situation any worse.

Thanks for your patience, this is on my radar but it’s looking like quite a big job so I’m working on it between other smaller tasks.

I’ve been using my own code for testing so far, but I’ll take a look at yours once I’ve made a bit more progress. Don’t worry about updating the project, I’m sure I’ll be able to work it out. I always appreciate having a code example, so thanks for putting that together!

2 Likes

it need not do all at once. we are happy also about smaller progress as the popup menu work in correct size. the window scaling is not so impoirtant as have popup menu in correct size. because popup menu need often to choose plugins.

I get now studio one 5.4 and i test unify in unify . it work ok now see screenshot

only problem with too small windows(about) and too small popup menu stay in. I test unify in studio one 4 maybe it is because unify is 1.6.2 . it work on studio one 4 too ok now.

this too small popup menu and too small windows for midibox or about window is a complete diffrent problem as the plugin scale for non 4k programed plugins.

the problem with the old vst plugins that look too small is a general problem and can solve with special windows programming, but then the plugins look blur. maybe this can help

Scaling unaware” apps:

Apps that only understand low DPI displays
On any other display, Windows bitmap stretches them to the right size

Majority of classic apps, weighed by app count

Some Windows tools (device manager)
  • Crisp and right-sized on low DPI displays
  • Right-sized but somewhat blurry on any high DPI display

@calvin Thank you for the feedback, but please remember this is the JUCE forum, not a Unify product forum. @reuk has indicated that he is working on this; I suggest we leave him do do so in peace.