Multi monitor Kiosk mode on Windows

1

Hi Juce team,
In brief : if you use setKioskModeComponent(getTopLevelComponent()) on Windows the app goes fullscreen only on the primary monitor. Looking around for causes this is pretty evident in the windows implementation on juce_win32_Windowing

Question : Is there a reason for this? (preventing going in kiosk mode on a secondary monitor or whatever monitor the app is currently in)
If not : Proposal we might replace the getMainDisplay line in the native windows implementation to:

kioskModeComp->setBounds(getDisplays().findDisplayForPoint(kioskModeComp->getScreenBounds().getTopLeft()).totalArea);

(also .getCenter() would do … honestly no ida of which point describes better an app being on a monitor or another.)

[sideNote #1] : Is there a reason why the windows setKioskMode call looks a lot more glitchy than the Mac one?
[sideNote #2] : while chasing around for “multimonitor kiosk mode” tried also to avoid the setkiosmodecomponent call and use a mix of setUsingNativeTitleBar(false) + setFullScreen but the kioskmode call seems to bee the only one reliably hiding all “accessories” such as the windows app bar or the application bar (which without the setkioskmode call went from a native one to a juce one … very puzzled by this)

1 Like
2

I don’t think there is any particular reason for this, and it’s been requested before. I’ve added this in 171b781.

There are a few places in the codebase where we use ComponentPeer::isKioskMode() to change the window behaviour by hiding title bars etc. Therefore just replicating what Desktop::setKioskComponent() does (ie setting a non-native title bar and resizing the component to the screen bounds) won’t have the same effect.

Can you elaborate by what you mean by this? Any differences are probably due to the fact that macOS natively supports a “kiosk mode” type window using a combination of NSApplicationPresentationOptions whereas on Windows this is all done by just resizing the JUCE window to fill the screen.

3

Thanks for the change! - tested it on mac and win and it looks good.

One thing : there was probably no need to change it on the mac native file juce_mac_NSViewComponentPeer.mm , if not for simmetry/elegance … the multi monitor kiosk already worked on mac, I suppose because the Apple native kiosk mac implementation first creates a new “Desktop” which already knows what monitor it’s displayed in, then kiosks the app in that new Desktop.
BTW tested your changes on Mac and, as expected, no regressions.

I’ve made a slow mo video comparing a juce test calling setKioskModeComponent (latest win 10 - vs 2019 - release x64) and Microsoft Edge “fullscreen” button.

First of all the Microsoft way of going kiosk is by no means comparable with the Apple way, the latter being much smoother, so that’s for sure a good 33% contribution to my perceived glitchiness.

But there are differences between Edge and the juce test,especially when going out of kiosk mode

  • the taskbar icon seems to do some domino thing, like it disappears then comes back sliding
  • the app seems first to go from kiosk mode to invisible, trhen go back to normal previous bounds.

here’s the slomo video → it’s at 240fps: download it and watch it with quicktime on mac (dropbox web player plays it back at normal speed)

and here’s the juce test code :

fullScreenButton.onClick = [this] 
    {
        ResizableWindow* resizableWindow = dynamic_cast<ResizableWindow*>(getTopLevelComponent());
        if(resizableWindow && resizableWindow->isKioskMode())
        {
            Desktop::getInstance().setKioskModeComponent(nullptr, false);
        }
        else if(resizableWindow)
        {
            Desktop::getInstance().setKioskModeComponent(resizableWindow, false);              
        }
}
4

@ed95 there is an additional related issue on Windows, where if you have a JUCE app fullscreen on one monitor, and click on anything on another monitor, the JUCE app pulls out of fullscreen mode.

5

Probably because of this line. I’m not sure it makes much sense in a multi-monitor setting as, like you’ve pointed out, the app can lose focus by just clicking on a different monitor. Hard to say whether removing it would cause any other issues though…

1 Like
6

Ok thanks, we’ll give it a go here and see how it goes…