I use LibreOffice with a netbook with 1024 x 600 pixel. I cannot reduce the height of the application window far enough, so that I can see and use the status bar. This was no problem in LibreOffice 4.2, but is a problem in newer versions. If you will force a minimal window height, it should be small enough to display the whole window on a netbook.
I can confirm this: I just switched from LO 4.4.6 to 5.0.3 by replacing "ppa:libreoffice/libreoffice-4-4" with "ppa:libreoffice/libreoffice-5-0" and there is the following issue: The LO window is too high for my 1024x600 netbook screen. I tried resizing the window, but even with smallest hight the window doesn't fit - it is exactly the status bar that is missing at the bottom. Or alternatively the window caption if the window is moved up. That is under all LO parts (Writer, Calc, etc.). Additionally, I noticed after the update that maximizing the window did not actually maximize it, but just made the window borders disappear. But I could work around that by resizing the width to fill the whole screen. Note: I usually use LO with its window maximized. And while all configuration settings seem to have been taken over from LO 4.4 to 5.0, the maximization (or the window width) was not - LO 5.0 started with a smaller window width after the update. System: - ASUS EeePC R101 netbook - 1024x600 screen, Intel on-board graphics - 2GB RAM - Linux Mint 17.1 MATE, 64bit (based on Ubuntu 14.04 Trusty; Kernel 3.13.0-37-generic; MATE 1.8.1)
P.S.: The original bug report was for 32-bit Windows. I changed the "Hardware" field to "All" since it also affects 64-bit Linux.
*** Bug 93862 has been marked as a duplicate of this bug. ***
Well, the system req. page says that 1024x768 is the minimum supported: http://www.libreoffice.org/get-help/system-requirements/
More details (like in bug 93862): LO actually starts with a correct window hight, but the window becomes too high after one closes a document. Test procedure: 1. Start LO 2. Click, e.g., on "Writer Document" to open an empty document 3. Close the Writer document (NOT the whole LO) 4. Click, e.g., on "Writer Document" to open an empty document Expected results: 1. LO starts maximized (from before closing), with correct hight 2. Empty document is opened with correct window hight - status bar is visible 3. Correct hight (one can see the "Help" and "Extensions" buttons correctly at the bottom) 4. Empty document is opened with correct window hight - status bar is visible Actual results: 3. Window too high - only the tops of the "Help" and "Extensions" buttons visible 4. Window too high - status bar not visible (can be made visible by moving the window up holding down the Alt key, but then the window caption disappears) Similarly if LO is started by opening, e.g., a Writer document on the disk - it starts with correct hight and just to the wrong one if the document is closed.
*** Bug 96027 has been marked as a duplicate of this bug. ***
Seems linked to the minimum height size for the StartCenter is "bleeding" over to the other modules. Suspect this is the case, as between 5.0.3.2 and current master we have added the Remote Files feature and the minimum window height for all components was bumped taller. The behavior of the StartCenter affects each component being launched from it, we are setting a minimum height for the component at that launch. The same component launched without use of the the StartCenter is not affected and its UI can be fully resized in height. But when that document is closed the UI height will resize to the minimum of the StartCenter backingWindow Suspect this is a unintended complication of Kendy's work on bug 91971
(In reply to V Stuart Foote from comment #7) > Suspect this is a unintended complication of Kendy's work on bug 91971 Actually it predates that considerably, and is present in the 4.2 builds--Kendy's patch for tdf#91971 just adjusted calculation of the minimum height to be able to hold all the button widgets of the MenuBar. Simple STR: 1. launch calc directly 2. resize to height desired 3. close calc -> opens start center 4. launch calc from start center 5. able to resize shorter than start center? No... Height of components has been bound to StartCenter from some point after the 4.2.0.4 release. Puts it right in the midst of major tweaking of the StartCenter backingwindow.cxx and backingcomp.cxx Seems the definition of the StartCenter minimum UI height is being picked up and incorrectly controlling height for launch all components. bisect... OK Version: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 BAD Version: 4.2.1.1 Build ID: d7dbbd7842e6a58b0f521599204e827654e1fb8b BAD Version: 4.2.2.1 Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f And all 4.3, 4.4, 5.0 and 5.1 builds.
Migrating Whiteboard tags to Keywords: (regression, bibisectRequest)
Just installed LO 5.1 (TDF -Version, not Ubuntu packages) on Acer Netbook (1024x600). It is even worse! Due to the additional icon in the Start-Center fits nothing. Smallest size of the window appears to be 1028x656 now. Unfortunately, there are always made new changes to the user interface. No real improvements.
Created attachment 122804 [details] zipped screenshots Screenshots of LibreOffice Portable 5.1 on Kubuntu Linux
I installed LibreOffice Portable 5.1 on a USB stick and started it on my netbook (1024x600 resolution) with linux (Ubuntu 14.04 / Wine 1.6). Unlike the Linux version 5.1 everything fits. Even as the taskbar is set to always visible. See my screenshots. This should also be possible with the Linux-Version.
*** Bug 98060 has been marked as a duplicate of this bug. ***
Modules being launched from the Start Center, i.e. STARTMODULE, are inheriting its height, but for bug 65826 (at 4.2.1.1), as adjusted in bug 91971 (at 5.0.0.2) we are establishing a minimum height for the Start Center. Meaning unfortunately that documents for modules launched from the Start Center can't be shrunk to fit a 600px display, or a users preferred frame size. @Caolán, Kendy -- instead of inheriting from the STARTMODULE when launched, could the starting size/placement also be recorded per module into the profile, and use taht? Expanding Caolán's work in https://cgit.freedesktop.org/libreoffice/core/commit/?id=b1314f22eb8de4359b5360194c04996351e9a6c2 and maybe provide enhancements for bug 75644
*** Bug 99682 has been marked as a duplicate of this bug. ***
Whoops, sorry for that duplicate. I'm having the same issue in an XFCE version of Puppy Linux, LO 5.0.4 and 5.1.1.3...
I've just updated from LO 5.0.6 to LO 5.1.3 (by changing ppa:libreoffice/libreoffice-5-0 to ppa:libreoffice/libreoffice-5-1) on Linux Mint 17.1, and it's even worse there: (In reply to Johnny_M from comment #5) > More details (like in bug 93862): LO actually starts with a correct window > hight, but the window becomes too high after one closes a document. That is no longer true - the LO StartCenter now always starts too high. > Test procedure: > 1. Start LO > 2. Click, e.g., on "Writer Document" to open an empty document > 3. Close the Writer document (NOT the whole LO) > 4. Click, e.g., on "Writer Document" to open an empty document > > Expected results: > 1. LO starts maximized (from before closing), with correct hight > 2. Empty document is opened with correct window hight - status bar is visible > 3. Correct hight (one can see the "Help" and "Extensions" buttons correctly > at the bottom) > 4. Empty document is opened with correct window hight - status bar is visible > > Actual results: > 3. Window too high - only the tops of the "Help" and "Extensions" buttons > visible > 4. Window too high - status bar not visible (can be made visible by moving > the window up holding down the Alt key, but then the window caption > disappears) So, the above steps 1 and 2 now fail, too - the window is too high on both. On a side note, the StartCenter maximization doesn't work either - the StartCenter starts with its window moved down about about the hight of the title bar, if started maximized. > Similarly if LO is started by opening, e.g., a Writer document on the disk - > it starts with correct hight and jumps to the wrong one if the document is > closed. That is still true. And the work-around, when one wants to create a new document bypassing the StartCenter, is to start the affected LO part directly. E.g., on Linux: - Writer: /usr/lib/libreoffice/program/swriter (alternatively: "lowriter" or "libreoffice --writer") - Calc: /usr/lib/libreoffice/program/scalc (alternatively: "localc" or "libreoffice --calc") etc. One could, e.g., create desktop launcher(s) pointing to them. One can then also open a new document of another LO part from within the one started (using File -> New in the menu), and it will open correctly.
I want to add my scenario here. But first I have to say the workaround with starting swriter directly work for me fine. I use a Samsung N220 netbook with 1024x600. The StartCenter can not be maximized (in my default config). I use Siduction (Debian unstable) with LXQt (xfwm4 as windowmanager) and LibreOffice 5.1.3.2 10m0(Build:2). I tried to install libreoffice-gtk3, libreoffice-gnome and libreoffice-kde packages (tricks I found on the web). Doesn't solve the problem. Setting the window manager to openbox solved the problem. The StartCenter now behave like expected without problems.
I'm in the process of switching from Puppy Linux to Mint, for reasons not germane to this bug. I can report that, for me, it seems to be fixed. Linux Mint 18, MATE flavor, LibreOffice 5.1.4.2. I can't say that's the initial version that Mint ships with -- I've applied a couple updates to the system since installing, and LO may have been affected by that (I think it was, but I wasn't paying enough attention to be sure). I'm going to mark this as Resolved/Fixed -- if anyone else is having a different experience, would they please reopen the bug? Thanks...
V 5.1.5, still reproducible. STR: 1) Open Lo main window 2) Open writer, try to resize
Issue still exists for me as in comment 17 with: - Linux Mint 17.1, 64-bit, MATE 1.8.1 (LTS, based on Ubuntu 14.04.1), from LO PPA: Version: 5.1.5.2 Build ID: 1:5.1.5~rc2-0ubuntu1~trusty1 CPU Threads: 2; OS Version: Linux 3.13; UI Render: default; Locale: de-DE (en_GB.UTF-8); Calc: group - Debian liveUSB, 32-bit, Gnome 3.18.2: Version: 5.2.2.0.0+ Build ID: f90be96ed400a5471d6c3a5cfa5087957803a9fe CPU Threads: 2; OS Version: Linux 4.3; UI Render: default; TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:libreoffice-5-2, Time: 2016-08-25_12:37:40 Locale: en-US (en_US.UTF-8); Calc: group Both on an Asus EeePC netbook with Intel Atom N450. On the other hand, I couldn't reproduce the issue with WinXP Home SP3, 32-bit on the same machine. Neither with the LO 5.0.5, nor with the LO 5.2.0 release. (Although the "Create:" icons in the Start Center of the latter are a bit too large - of "Base Database" only the top is visible, but the "Help" and "Extensions" buttons appear correctly.)
Created attachment 127040 [details] Screenshots LibreOffice 5.2.0 and LibreOffice 5.2.0 PORTABLE
Problem still exist for me. I am using now LO 5.2.0 TDF-Version not from the repositories on Kubuntu-Linux 14.04 netbook with screen 1024x600) KDE has the possibility to force the windowsize of 1024x600. So I can work. It just amazes me that LibreOffice 5.2.0 PORTABLE is running on my netbook with correct window size under Wine (Windows replacement on Linux).
This issue exists both on Linux Debian and others and on MS Windows 8.
*** Bug 104304 has been marked as a duplicate of this bug. ***
*** Bug 104324 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** Bug 114079 has been marked as a duplicate of this bug. ***
*** Bug 114483 has been marked as a duplicate of this bug. ***
Created attachment 140669 [details] LibreOffice 5 running on Dell 5855 FullHD Hello! > Well, the system req. page says that 1024x768 is the minimum supported Maxim, issue is reproducible on following configurations: 1280x800 Lenovo Miix2 8 1280x720 Dell 5855 HD 1920x1080 with default 200% scaling - Dell 5855 FullHD All mentioned devices is 8 inch tablets running Ubuntu 17.10. Screenshot from latest device is attached - additionally, there LibreOffice refuse to switch fullscreen for some reason, probably because it doesn't like 1920x1080 with 200% scaling (which probably translates to 960x540). So, all configurations is meet system requirements.
Bisected with 43max to commit 9b23875ab461a73e0f97812500def130b265f73e Author: Matthew Francis <mjay.francis@gmail.com> Date: Thu May 28 18:29:38 2015 +0800 source-hash-840e7f004354ebe1239b9271dd758839c477ca7c commit 840e7f004354ebe1239b9271dd758839c477ca7c Author: Zolnai Tamás <tamas.zolnai@collabora.com> AuthorDate: Fri Jan 17 20:10:06 2014 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Tue Jan 21 15:42:57 2014 +0000 fdo#65826 and fdo#73605: set a minimum size to start center This minimum size calculated like this: width: sidebar optimal width + width of text appearing in the thumbnail view when no recent document is available. height: menu width + optimal width of GtkBox containing buttons. Adding Cc: to Tamás Zolnai
what we could try is to save the orig min size and restore it after the start centre is replaced. https://gerrit.libreoffice.org/#/c/57722/
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fce3d0eec508c14beb2bc4ad3b7982abf6ec3c4a tdf#93085 restore orig min window size after startcenter... It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I wonder if that commit keeps everyone happy wrt this bug ?
(In reply to Caolán McNamara from comment #34) > I wonder if that commit keeps everyone happy wrt this bug ? Buovjaga, You bisected this bug... Is it fixed after Caolán commit ?
(In reply to Xisco Faulí from comment #35) > (In reply to Caolán McNamara from comment #34) > > I wonder if that commit keeps everyone happy wrt this bug ? > > Buovjaga, You bisected this bug... > Is it fixed after Caolán commit ? Yes, the minimum height restriction for modules is gone. Caolán was wondering about reporter happiness - no comment about that, but let's close. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: aaa3c31ba79b1b3d335dcf55d72837a13411b45e CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on September 11th 2018
The old behavior is once again present in LibreOffice 6.0.7 and in 6.1.4 both, at least on 64-bit Debian-based OSes. I manually installed 6.1.4.2 over whatever 6.0.7.x version came with Xubuntu 18.04 (my current OS) and this did not resolve the issue. If I open LibreOffice to the Start Center, it will not size to my 1024x600 screen. If I open a document from the file manager, it will. I suppose something got rolled back after a bit... unfortunately. It would be nice if this were fixed again in the next revision of LibreOffice, and considerably nicer if it actually stayed that way this time.
(In reply to Christopher from comment #37) > The old behavior is once again present in LibreOffice 6.0.7 and in 6.1.4 The fix in comment 33 was applied to the (coming) version 6.2 and later. Not those. Please re-open if present in LO 6.2 - see https://qa.blog.documentfoundation.org/2019/01/11/libreoffice-6-2-rc2-is-ready-for-testing/ for release details. Closing again for now.
Oh, sorry. I apologize... I should have read the thread more carefully! (This is especially embarrassing since I usually insist that *others* do as I have failed here.) I look forward to LO 6.2 then :) and in the meantime, once again, sorry for being a bit of an idiot.
*** Bug 127788 has been marked as a duplicate of this bug. ***