UI Zoom Factor

[ulrik]

I'm building a standalone app with Hise, in FLT "CustomSettings" I have UI Zoom Factor set to 100%.
I have

Content.makeFrontInterface(1280, 740);

and my computer has a display with

(1280 x 800)

However when I open the compiled standalone it is smaller than 100%, (but the UI Zoom Factor is still set to 100%), so I set the UI Zoom Factor to something else than 100% and then set it back to 100%, and then it scales down/up to 100%.

How come it doesn't scale to 100% when launching it (even when it's set to 100%)?

Has it to do with my

Content.makeFrontInterface(1280, 740);

and that Hise scales it down automatically at some range?

[d.healey]

My guess would be that this is a project you've opened before and it's written the zoom setting to a file in the appData folder.

[ulrik]

@d-healey Aha, ok I'll check, thanks!

[ulrik]

@d-healey Hm.. that was not the cause

[Christoph Hart]

If the user's screen is smaller than the UI height at 100% (minus the OS toolbar) it defaults to 85% so that the interface is not capped.

[ulrik]

@Christoph-Hart Ok I understand, could we in some way script the UI Zoom setting?

[Christoph Hart]

Yes, that's a reasonable request. It's actually pretty easy to do, so maybe someone else can implement it:

1. fetch a reference to the main controller and dynamic_cast it to AudioProcessorDriver
2. call driver->setGlobalScaleFactor(scaleFactor, sendNotification); (the last parameter is important to that it sends a message to the UI to resize).
3. Add a API call Engine.setZoomLevel(double scaleFactor) (it's a bit inconsistent to the C++ naming, but it matches the Engine.getZoomLevel() call).

EDIT: Oh and if you want to disable the 85% scaling, just remove the condition here:

HISE/hi_frontend/frontend/FrontendProcessorEditor.cpp at 8ef678ec2fcae0973cc269163404b1f9df967733 · christophhart/HISE

The open source framework for sample based instruments - HISE/hi_frontend/frontend/FrontendProcessorEditor.cpp at 8ef678ec2fcae0973cc269163404b1f9df967733 · christophhart/HISE

GitHub (github.com)

[ustk]

@Christoph-Hart gorgeous, I’ll give it a go sometimes tomorrow

[ulrik]

@Christoph-Hart Beautiful, thank you!

[ulrik]

@ustk Yezzz...great! You'll get a bear as well

[Dan Korneff]

[Natan]

@Christoph-Hart said in UI Zoom Factor:

message to the UI to resize).

Oh Wow, Thank You
Any Examples is much appreciated

[ustk]

@Christoph-Hart So I've made the API, but it is of course non-dynamic, as the plugin has to be closed and reopened like for the norm zoom factor setting.
So the question is, is it easily doable to have it resized in real-time using the same API, or is it a totally different approach?

[Christoph Hart]

Did you use sendNotification? It's basically the same thing that the combobox of the settings dialogue does.

[ustk]

@Christoph-Hart Yes

void ScriptingApi::Engine::setZoomLevel(double scaleFactor)
{
	auto mc = getScriptProcessor()->getMainController_();
	AudioProcessorDriver* driver = dynamic_cast<AudioProcessorDriver*>(mc);

	driver->setGlobalScaleFactor(scaleFactor, sendNotification);
}

or

void ScriptingApi::Engine::setZoomLevel(double scaleFactor)
{
	auto mc = getScriptProcessor()->getMainController_();
	dynamic_cast<AudioProcessorDriver*>(mc)->setGlobalScaleFactor(scaleFactor, sendNotification);
}

which is the same thing

[ustk]

@Christoph-Hart I think we need this

#if USE_FRONTEND

	auto fpe = mc->findParentComponentOfClass<FrontendProcessorEditor>();

	if (fpe != nullptr)
	{
		fpe->setGlobalScaleFactor((float)scaleFactor);
	}
#endif

then findParentComponentOfClass must be adapted but I don't know how...

What's the difference between getScriptProcessor()->getMainController_(); and getProcessor()->getMainController();?
Both are working...

[Christoph Hart]

They are both the same (and one just calls the other method with a dynamic cast).

Ah I see the problem (not sure how I could have missed that when I wrote my last answer). The editor window is not registered to the ScaleFactorListener system (which is weird because the system is made exactly for this purpose). I think I have to take it from here and clean up my own mess :)

[ustk]

@Christoph-Hart Nice, I've just seen you implemented it yourself ;)

You also corrected the macOS compilation, but I still have the same issue when compiling:

[Christoph Hart]

Yeah, I accidentally committed this to the SNEX branch, it was meant to go to the Scriptnode branch, but I'll transfer it real quick.

[ustk]

This post is deleted!