Bug 116290 - UI: Window size limited by length of menu bar (gtk3 only?)
Summary: UI: Window size limited by length of menu bar (gtk3 only?)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.2.0.1 target:6.3.0 target:6.1.5
Keywords:
: 121911 (view as bug list)
Depends on:
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2018-03-08 10:53 UTC by Roy Reese
Modified: 2019-01-15 02:04 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
LO 6 Writer screenshot (120.95 KB, image/jpeg)
2018-03-08 20:38 UTC, Roy Reese
Details
LO 6 Calc min window width (160.44 KB, image/jpeg)
2018-03-08 20:41 UTC, Roy Reese
Details
LO_6_Win7_shot (19.73 KB, image/jpeg)
2018-03-09 06:32 UTC, Roy Reese
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roy Reese 2018-03-08 10:53:20 UTC
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.
Comment 1 Roy Reese 2018-03-08 11:00:05 UTC
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
Comment 2 V Stuart Foote 2018-03-08 16:40:28 UTC
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?
Comment 3 Roy Reese 2018-03-08 20:38:50 UTC
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.
Comment 4 Roy Reese 2018-03-08 20:41:04 UTC
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.
Comment 5 Roy Reese 2018-03-09 06:32:38 UTC
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.
Comment 6 Thierry Vignaud 2018-03-09 09:09:51 UTC
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
Comment 7 Caolán McNamara 2018-03-10 21:28:36 UTC
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.
Comment 8 Roy Reese 2018-03-14 08:46:39 UTC
"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.
Comment 9 Thierry Vignaud 2018-03-14 08:53:26 UTC
And that was the behavior of the x11/gtk2 build if I remember right
Comment 10 Xisco Faulí 2018-10-24 11:14:27 UTC
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.
Comment 11 Roy Reese 2018-10-24 13:01:57 UTC
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.
Comment 12 russianneuromancer 2018-10-29 07:27:27 UTC
Roy, please check 6.2.0.0 as bug 93085 could be related.
Comment 13 Roy Reese 2018-11-08 11:31:58 UTC
Finally downloaded 6.2 and the problem is still present.
Comment 14 Caolán McNamara 2018-12-14 15:16:33 UTC
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
Comment 15 Commit Notification 2018-12-15 00:58:43 UTC
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.
Comment 16 Commit Notification 2018-12-15 00:58:52 UTC
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.
Comment 17 Commit Notification 2019-01-11 16:27:28 UTC
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.
Comment 18 Adolfo Jayme 2019-01-15 02:04:07 UTC
*** Bug 121911 has been marked as a duplicate of this bug. ***