[upstream] Minimum window width doesn't fit on screen in portrait mode

[Alexander Kallenbach]

As described above. I've turned my screen around to work in portrait mode. Sadly LibreOffice came out of the full screen mode. Full screen mode seems not to be possible on portrait mode. The window didn't fit into the screen and therefore it isn't possible to work with LibreOffice in portrait mode. I'll attach a screenshot to clarify what I mean.

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: libreoffice-writer 1:6.1.2-0ubuntu1.1
ProcVersionSignature: Ubuntu 4.18.0-11.12-generic 4.18.12
Uname: Linux 4.18.0-11-generic x86_64
ApportVersion: 2.20.10-0ubuntu13.1
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sun Dec 2 22:52:10 2018
InstallationDate: Installed on 2018-11-30 (2 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)

[canonmp190 (canonmp190)]

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.

[canonmp190 (canonmp190)]

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

[Vstuart-foote (vstuart-foote)]

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?

[canonmp190 (canonmp190)]

Created attachment 140486
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.

[canonmp190 (canonmp190)]

Created attachment 140487
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.

[canonmp190 (canonmp190)]

Created attachment 140495
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.

[Thierry-vignaud (thierry-vignaud)]

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

[Caolanm (caolanm)]

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.

[canonmp190 (canonmp190)]

"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.

[Thierry-vignaud (thierry-vignaud)]

And that was the behavior of the x11/gtk2 build if I remember right

[Xiscofauli (xiscofauli)]

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.

[canonmp190 (canonmp190)]

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.

[RussianNeuroMancer (russianneuromancer)]

Roy, please check 6.2.0.0 as bug 93085 could be related.

[canonmp190 (canonmp190)]

Finally downloaded 6.2 and the problem is still present.

[Olivier Tilloy (osomon)]

Do you mean fullscreen, or maximized window?

Note that this likely not specific to libreoffice. The application just happens to enforce a minimum window width that appears to be larger than the width of your screen when in portrait orientation. That would affects similarly other applications that enforce a minimum width for their windows.

Regardless, would you mind filing an upstream bug report at https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice&format=guided, to get upstream's take on the problem? Please share the link to that bug report here. Thanks!

[Alexander Kallenbach (kallenbachalex)]

I meant maximized window. There other applications which are affected as well. My screen has a resolution set to 2550*1440, scaling is set to 200% (sadly it isn't possible to set scaling to 150%).

I will create a bugreport upstream as well.

[Alexander Kallenbach (kallenbachalex)]

Description:
I've turned my screen around to work in portrait mode. Sadly LibreOffice which has been maximized came out of this mode. I'm not able to use LibreOffice in a maximized window. The window didn't fit into the screen and therefore it isn't possible to work with LibreOffice in portrait mode. I'll attach a screenshot to clarify what I mean.

I'm on a machine running Ubuntu 18.10. My screen has a resolution set to 2550*1440, scaling is set to 200% (sadly it isn't possible to set scaling to 150%).

I've already created a bugreport on launchpad: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1806292?comments=all

Steps to Reproduce:
1. Open LibreOffice
2. Turn your laptop to use it in portrait mode

Actual Results:
Maximized window isn't possible. Window doesn't fit to screen. Effective working not possible.

Expected Results:
Maximizing is possible even in portrait mode.

Reproducible: Always

User Profile Reset: No

OpenGL enabled: Yes

Additional Info:

[Alexander Kallenbach (kallenbachalex)]

Created attachment 147290
screenshot

[Alexander Kallenbach (kallenbachalex)]

Upstream bugreport: https://bugs.documentfoundation.org/show_bug.cgi?id=121911

[Olivier Tilloy (osomon)]

Thank you Alexander.

[Caolanm (caolanm)]

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

[Libreoffice-commits (libreoffice-commits)]

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.

[Libreoffice-commits (libreoffice-commits)]

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.

[Libreoffice-commits (libreoffice-commits)]

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.

[Adolfo Jayme Barrientos (fitojb)]

This should be fixed in the next version

*** This bug has been marked as a duplicate of bug 116290 ***

[Adolfo Jayme Barrientos (fitojb)]

*** Bug 121911 has been marked as a duplicate of this bug. ***

[Sebastien Bacher (seb128)]

The upstream bug suggests it's going to be fixed in 6.1.5 and 6.2.0.1