At least in Mageia Linux the width of a LibreOffice window cannot be smaller than the length of the menu bar. To replicate, open a LO component and reduce the width of the window. It can be reduced to the full size of the menu (not tool) bar, but not farther. If resizing before LO has loaded completely it is possible. However, as soon as the menu bar appears the window is resized to accommodate the bar. This behaviour appears in both Mageia 6 with LO 5.4.3.2 and Cauldron (Mageia 7) with LO 6.0.2.1.0. I have tried it in both my main DE (Enlightenment) and IceWM with the same results. The expected behavior, of course, is that items on the menu bar will simply be covered over/disappear as the width is reduced which I have seen in a Windows 7 installation. Things that I have tried in Mageia: 1) Changing the theme: this problem appears with the Vertex and Adwaita themes (light and dark in both) 2) Removing the Spanish language pack: the problem appears with US English as well. I have not tested this with Plasma or LXQt. For English language installations this is not much of a problem, but I have my systems set up in Spanish with the Anaphareus extension to LO Writer. It adds itself to the menu bar and now prevents me from reducing window size below about 60% of the screen width. I suspect there may be other languages for this will be a problem as well.
Note that a couple of people on the mailing list indicated that this problem did not appear in their Linux versions (Puppy, Mint, openSuse). Mageia bug report for cross reference: https://bugs.mageia.org/show_bug.cgi?id=22671
Some screen clips would be helpful, not clear if you are refering to the Client Side Decorations of the frame or the text Menu. On Windows builds the application frame can be reduced until elements of the CSD no longer fit (Document & Program title [collapses to minimum], Iconify button, Maximize button, Close Frame button). While on shrinking the program Menu receives a >> adding hidden menu items to a GUI drop list for selection. So assume you are not seeing a >> widget for the Menu appear as the frame shrinks?
Created attachment 140486 [details] LO 6 Writer screenshot Screenshot showing the minimum width of LO Writer = menu bar (Archivo --> Ayuda) plus the "x" document close button. Starting from full screen width the window can be shrunk to this width, but no further. In windows, the width can be reduced further as menu items are simply covered.
Created attachment 140487 [details] LO 6 Calc min window width Note that this window is considerably more narrow than the LO Writer window because there are fewer menu items across the top. Again, the minimum width is the length needed for all the drop-down menus plus the "x" to close the current document.
Created attachment 140495 [details] LO_6_Win7_shot This picture of LO6 Writer in Windows 7 shows a width that is smaller than the menu bar. Note the "x" on top of one of the menu items. In Win7 the window can be made even smaller.
I'm seeing the same with 5.4.5.1-1.fc27 on FC27 Also with 6.0.2.1-1.mga7 on Mageia Cauldron. Maybe the GtkMenuBar should be in a ScrolledWindow with an invisible scrollbar? It might be regression of the gtk+3 port
Its a native GtkMenuBar inside a toplevel GtkWindow. So presumably the min size is that of its contents. GtkToolBar comes with a "show-arrow" property which allows the toolbar to be shrunk past the size of its contents and show the entries in an overflow menu. I see no such properties with a GtkMenuBar, so I think that's just the way it is with a native gtk menubar so someone probably needs to ask upstream gtk if there's a mechanism to achieve this, if it even is something that should be desirable. Sticking it into a scrolledwindow would just leave the excess elements unusable.
"Sticking it into a scrolled window would just leave the excess elements unusable." As it has done and still does in Windows. There are simply times when it is desirable to have the window smaller as when working with two documents side by side. Having access to the window items is no problem as one simply widens the window temporarily. In addition, one also has keyboard shortcuts that can be used. I would also argue that having a narrow window is likely something one will use for specific tasks/in specific circumstances and not as the default. So in most situations one would still work with a window giving access to all the items. Two factors gave rise to discovering this behavior. First, an extension that added itself to the menu bar. Perhaps this can/should be changed. I will raise that issue with the extension author, but am not sure it need be viewed as especially problematic. Second, the size of the menu being driven by the language of the UI, given that the space needed is determined by the length of the words/symbols used for the item (in this case, Spanish words taking up more space). This is likely not something that can be changed, so having the flexibility of simply covering some items from time to time will be more important in some cases than others.
And that was the behavior of the x11/gtk2 build if I remember right
Hello Roy Reeese, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Versions are getting a bit confusing at this point: 6.1.2 - the version in your link 6.1.3.1 - my installed version in Mageia, where the bug is still present 6.2 alpha - appears on the bugzilla page - not tested On the assumption that you indeed wanted a "fresh," not alpha, version, the bug is being reset to UNCONFIRMED.
Roy, please check 6.2.0.0 as bug 93085 could be related.
Finally downloaded 6.2 and the problem is still present.
looks like GTK_POLICY_EXTERNAL for a GtkScrolledWindow could be used to get this to work https://developer.gnome.org/gtk3/stable/GtkScrolledWindow.html#GtkPolicyType
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/da9e424c556e25cf42eddc9d6fa22011e80359aa%5E%21 tdf#116290 allow menubar to shrink past its minimum size It will be available in 6.2.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/4f4f74642838d19278339fac9f8bc75ed8bfe1d5%5E%21 tdf#116290 allow menubar to shrink past its minimum size It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-1": https://git.libreoffice.org/core/+/10d1a285511bc9109f44cc6da2558d820bef321c%5E%21 tdf#116290 allow menubar to shrink past its minimum size It will be available in 6.1.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 121911 has been marked as a duplicate of this bug. ***