It's a similar problem with the missing layout as in D10248.
I tried to set a couple of minimum sizes / size hints for FullScreenContent and FullScreenBar, but they don't reach the QSplitter because of the missing layout connection.
This patch will not win a beauty contest, but it's the only way I found: setting a minimum width hint for ViewMainPage::minimumSizeHint() to respect both the toolbar and the status bar width if visible.
Maybe there's an obvious solution I don't see (other than adding a custom layout)?

In D10458#204838, @muhlenpfordt wrote:

This patch will not win a beauty contest

As long as you don't introduce any hardcoded pixel sizes, it should be fine ;)

Checked status bar toggling on/off (F3) to correctly adjust width.

Oh, you are working on the statusbar too? ;)

Still, I can get it to break: Switch off thumbnails with the slideshow configure button, choose image with long filename (obligatory new bug filed for the renaming problem…).

Maybe there's an obvious solution I don't see (other than adding a custom layout)?

Without looking too deep into it: When reviewing the other patch, the general size hints still seemed to work. Only the event propagation from the outside was interrupted due to the missing layout. Perhaps we can just bridge this gap?

You did that by remembering mFullScreenMinimumWidth, but still rely on Qt in the beginning by calling mFullScreenContent->minimumWidthHint(). I assume that's exactly where I could break it, because this call would yield something different for the other layout case while your variable does not change. Instead of accessing your new member variable (and fixing/bodging it to be updated), could you try to call the function directly, possibly via something like parentWidget() which might be independent from the non-existing layout linkage?

In D10458#205039, @rkflx wrote:

As long as you don't introduce any hardcoded pixel sizes, it should be fine ;)

That's what I wanted to avoid. ;)

Oh, you are working on the statusbar too? ;)

Not yet - just noticed that I squished the statusbar instead of the toolbar sometimes.

Still, I can get it to break: Switch off thumbnails with the slideshow configure button, choose image with long filename (obligatory new bug filed for the renaming problem…).

Didn't we want to get one bug less... ;)

It's a bit different here since the size hint is not an event. But maybe it's really possible to get a direct connection for this, let's see.

Found a better solution which uses the size of FullScreenContent's internal layout. Maybe the bridge you imagined? ;)
This way the width is correctly updated with or without thumbnails visible and while changing info label width.
It's not possible to store a pointer to the layout only since this is destroyed and recreated while toggling thumbnail view. A pointer to a standard QWidget is stored and its actual layout() is asked in ViewMainPage::minimumSizeHint().

Thanks, I'll look at it in more detail later (and maybe I'll find a way to get rid of mFullScreenOverlay). Quick testing showed it working much better, but I can still break it by setting a really loooong filename (in both modes).

Perhaps you'd need to set an upper limit for the minimum size of the filename label?

In D10458#205497, @rkflx wrote:

Perhaps you'd need to set an upper limit for the minimum size of the filename label?

Playing a bit with the mInformationLabel->setSizePolicy() and setting both values to QSizePolicy::Ignored seems to solve this issue for really long filenames, without or including spaces where QLabel can break the string. I'll take a closer look...

In D10458#205039, @rkflx wrote:

Instead of accessing your new member variable (and fixing/bodging it to be updated), could you try to call the function directly, possibly via something like parentWidget() which might be independent from the non-existing layout linkage?

Well, if the parents are clueless, we just ask their children:

diff --git a/app/fullscreencontent.cpp b/app/fullscreencontent.cpp
index 41bd86db..8b7bd971 100644
--- a/app/fullscreencontent.cpp
+++ b/app/fullscreencontent.cpp
@@ -123,6 +123,7 @@ void FullScreenContent::init(KActionCollection* actionCollection, QWidget* autoH
 
     // mContent
     mContent = new QWidget;
+    mContent->setObjectName("mContent");
     mContent->setSizePolicy(QSizePolicy::Expanding, QSizePolicy::Fixed);
     mContent->setAutoFillBackground(true);
     EventWatcher::install(mContent, QEvent::Show, this, SLOT(updateCurrentUrlWidgets()));
diff --git a/app/viewmainpage.cpp b/app/viewmainpage.cpp
index 0c84c29c..e352a831 100644
--- a/app/viewmainpage.cpp
+++ b/app/viewmainpage.cpp
@@ -58,6 +58,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
 #include <lib/thumbnailview/thumbnailbarview.h>
 #include <lib/zoomwidget.h>
 #include <lib/zoommode.h>
+#include <fullscreenbar.h>
 
 namespace Gwenview
 {
@@ -580,7 +581,10 @@ QSize ViewMainPage::minimumSizeHint() const {
     if (window()->isFullScreen() && d->mFullScreenOverlay && d->mFullScreenOverlay->layout()) {
         // Check minimum size of the fullscreen overlay widget
         // since there is no layout link which could do this
+        const int fullScreenBarWidth = findChild<FullScreenBar*>()->layout()->minimumSize().width();
         if (d->mFullScreenOverlay->layout()->minimumSize().width() > minimumSize.width()) {
+            qDebug() << d->mFullScreenOverlay->layout()->minimumSize().width()
+                     << fullScreenBarWidth;
             minimumSize.setWidth(d->mFullScreenOverlay->layout()->minimumSize().width());
         }
     }

In D10458#205793, @rkflx wrote:

Well, if the parents are clueless, we just ask their children:

Sure - that's an idea. :)
Maybe a little slower than my approach, but that really doesn't matter here and looks much better.

Any reason why you cast to FullScreenBar and not a standard QWidget searching for objectName?

In D10458#206063, @muhlenpfordt wrote:

Any reason why you cast to FullScreenBar and not a standard QWidget searching for objectName?

Ok, changed my mind. ;)
Searching for FullScreenBar is saver and needs no string compare.