Ubuntu Full Screen Size Not Correct Until Repaint

This is probably user error, as I’m pretty new to JUCE. I can’t seem to make setFullScreen(true) to have the desired behavior (on Ubuntu 18.04).

I would like to set the MainWindow to fullscreen, and then set the size of the MainComponent to take up the full size of the MainWindow.

I have called setFullScreen(true) on MainWindow, and I’ve tried a few different things to set the size of the MainComponent, one of them being the following:

auto userArea{juce::Desktop::getInstance().getDisplays().getPrimaryDisplay()->userArea};
setSize(userArea.getWidth(), userArea.getHeight());

It seems that when the app is first opened it has the full height of the screen, and only after an initial interaction (like a mouse movement) does it actually get resized to the true userArea size.

I’ve set a DBG statement inside my MainComponent::resized function and see the following (the first message is on the initial call to resized called after the constructor, the second is after slightly moving the mouse):

Screenshot from 2021-11-24 22-12-13

I’ve scoured the forums and docs and haven’t found anything yet. Any insights would be appreciated.

There were changes related to full screen behaviour in Linux recently, so just make sure you are using 6.1.2 or develop.

There are a couple of variables to play with here. You could set a constant size to MainComponent and it should still fill your screen when calling setFullScreen (true). You could check that you are calling setFullScreen after the window has been added to the desktop. If you can’t see an explicit call to addToDesktop() after setFullScreen() this should be the case.

Also on Linux the behaviour will be different if you use setUsingNativeTitleBar (true) or not. In the former case the window will cover the taskbar (like on MacOS), in the latter it will leave it unobstructed.

I couldn’t reproduce the exact situation you mentioned with any combination of these settings, but if you share a test project that produces this behaviour, I will take a look at it.

Thanks so much for your reply. I’ve uploaded a small repo to the following location that reproduces this behavior:

Also, I guess it was obvious but I should have noted that the DBG statement was logging out the height of the MainComponent. I have a GIF that also shows the behavior:


This does have a native title bar but the gif capture software didn’t capture that part of the screen.

Thanks for taking a look!

Thank you for the example. With it I could understand what the problem is, although it’s not producing the bug on my GNOME Ubuntu.

Unfortunately the Displays::Display::userArea implementation is lacking on Linux and will return the totalArea. So what happens in your case I think, is that you set the window’s size to the totalArea, covering the dock, and when you interact with it your desktop environment forcibly reduces its size to the actual user area.

The reason the userArea is limited for now, is that there doesn’t seem to be an easy or robust way in X11 to query the user area in a way that would also work with multiple monitors. I believe this is why _GTK_WORKAREAS_Dx has been added to GNOME lately, but it’s not something that will work with every Linux distro old an new.

setFullScreen (true) on the other hand should work correctly when using the native titlebar (as your sample project does). Using that instead of userArea should resize your window to the actual user area, because it will just instruct X11 to maximise the window. You can completely omit the usage of userArea, and just provide a constant size in your main Component's constructor and it should still fill out its parent window when maximising.

Can this approach work for you?

1 Like

Thanks so much for looking into this - I haven’t looked nearly as deeply into the linux api as I would like to so I appreciate the explanation!

I must be overthinking this, but I have tried all sorts of combinations of setFullScreen(true) vs setFullScreen(false) and some actual size, but can’t seem to get it to work. Here’s what I’ve seen:

NOTE: all gifs except the last one should have a app bar at the bottom of the screen (it was visible on my computer). The last gif is the only one that was truly “kiosk” mode without an app bar visible. The screen cap software was a little misleading.

The first attempt was to use setFullScreen(true) and then not set the size of the child component at all. That seems to work on first render, but it results in this assertion failure which checks if the size > 0:
Screenshot from 2021-11-29 21-36-34

Also, when I “un-maximize” the window (if that’s a word?), it collapses to nothing, as seen below (forgive the top being cut off - I had to keep screen capture a little smaller to get access to my app title bar):

Then, when I use setFullScreen(true) and set MainComponent size to some dimensions (here I’ll use 800x800) so that there is no assertion failure, I get an 800x800 window until I interact with the app, when it then goes fullscreen:


Finally, if I don’t use setFullScreen(true) but instead set the size of the MainWindow to the userArea and then set an explicit size of MainComponent to 800x800, I essentially get a kiosk mode app (the top is cut off again due to screen capture software, but it is full height of the monitor):


Anyways, I’m not too worried about it, as my target architecture for an upcoming project will be mobile (and a plugin), so this issue isn’t a show stopper for me. I just wanted to share my findings and I’d also like to start to contribute to the source code (as I’m getting more familiar) so I’m using this as an opportunity to learn more.

Lastly… I lied a little (don’t hate me!). I’m not REALLY on Ubuntu proper… I’m on ZorinOS 15. But, it really is Ubuntu underneath:

Screenshot from 2021-11-29 21-50-08

So maybe it’s specific to this distro - but just wanted to share my findings. I’ll carry on with my work regardless; thanks for this fantastic framework!