This bug report pertains to Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: adf65471e889676a600a9c6d0454c75cbd549ad3 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-08-13_04:44:18 Calc: threaded This is a very annoying bug related to window roll up in conjunction with LibreOffice Writer (and possibly other LO programs and other versions of it). Probably "roll up window" (German: Fenster einrollen) is an operating system function, but the application programs have some influence on it, at lest by enforcing a reasonable minimum width of their program window. I can prevent activating the function "roll up window" by rolling the mouse wheel on my computer with Xubuntu 18.04 via Settings>Fine settings of the window management>Accessibility>use the mouse wheel above the title bar to affect the window roll up. But there seem to be more ways to accidentally activate this annoying function like double clicking on the title bar and the like. At least in Linux with xfce there is no switch "prevent rolling up windows by all means" - according to https://forum.xfce.org/viewtopic.php?id=13489 ad I guess things might be similar in other operating systems. Most GUI programs have a fixed limit below which you cannot reduce the width of their program window. LibreOffice is different: If there is no toolbar on the left side of the screen, you can make the LibreOffice window so narrow that when it is rolled up, only the off button or only a portion of it remains visible! Then it is extremely difficult to unroll the window at all. At least LibreOffice would have to implement a minimum limit for narrowing its window. I don't know if this is possible in addition to refuse to roll up at all. Steps to reproduce: 1. Open a window with LibreOffice Writer unter an operating system which has a function "roll up window" like Xubuntu, Ubuntustudio and the like (probably all versions with xfce and possibly also other operating systems). 2. If you have a vertical toolbar active in LO Writer: turn it off. 3. Make the LO Window as narrow as possible. 4. Invoke the operating system's function to roll up (i.e. only leave the title bar visible) 5. Try to get out of the situation without loosing edits in the LO window.
I understand your frustration, but this doesn't sound like a LibreOffice issue to me. Undoubtedly there are many other applications for which you could run into the same situation. This is a usability problem that xfce needs to solve for itself.
(In reply to Michael Warner from comment #1) > I understand your frustration, but this doesn't sound like a LibreOffice > issue to me. Undoubtedly there are many other applications for which you > could run into the same situation. This is a usability problem that xfce > needs to solve for itself. Yes and No: LO's windows can be made so narrow that they reduce to the close button! If you narrow LO's window from the right, it can be made so narrow that no control button remains visible! LO should limit its minimum width to something like 5 cm to prevent the windows manipulation buttons from becoming inaccessible - like most other applications do! I have checked a dozen other ones: None of them could be made narrower than 5 cm or so. The button to roll out the window remains visible with them. It's another question, whether or not LO's code gets involved, when the operating system wants to roll up its window. If it gets involved, then there would be an option to refuse rolling in. This would avoid strange situations for new and advanced users.
I tested reducing the width and on KDE it stops when the top window controls would disappear. So it really seems to be an Xfce issue, if they allow the window to "swallow up" the controls.
(In reply to Buovjaga from comment #3) > I tested reducing the width and on KDE it stops when the top window controls > would disappear. So it really seems to be an Xfce issue, if they allow the > window to "swallow up" the controls. I guess it is possible to programmatically request a minimum window width. It should be set to something like 5 cm. Probably it is also possible to prevent rolling in completely by proper programming. The annoying roll in feature triggered a discussion at https://askubuntu.com/questions/621133/change-minimum-size-of-a-window where someone is complaining about "sublime text" and the answer is "There is no way you can change the min. window size in regards to resizing. That is up to the app to do & in the case of sublime it doesn't. Altering this is done in source & as sublime is closed source your best bet is to file a bug with them."
Sorry, I was not testing this properly. While the width adjustment does snap to the window control width at first, I am able to make it into a thin line with kf5 and gen backends and mere closing button width on gtk3, if I resize to "negative width". This does not happen on Windows. The Start Center never goes narrower than its application launch panel. So let's set to NEW.
I think we can mark this as a duplicate of bug 97894: having a minimum window size on Linux should fix the issue described here. Please set back to "new" if you disagree. *** This bug has been marked as a duplicate of bug 97894 ***
(In reply to Stéphane Guillou (stragu) from comment #6) > I think we can mark this as a duplicate of bug 97894: having a minimum > window size on Linux should fix the issue described here. > Please set back to "new" if you disagree. > > *** This bug has been marked as a duplicate of bug 97894 *** I'm afraid you may be right about that. Unfortunately, 97894 is also a bug that has been waiting for an even longer time to be fixed. And comment 3 there seems to name also already a function which to call, only about the suitable minimum value Caolán McNamara was uncertain! BTW: #125543 also might be another candidate for duplicateship! I came across it searching how one would have to call SetMinOutputSizePixel to implement a minimum width of 5 cm as I proposed above. Unfortunately I found no description for SetMinOutputSizePixel. But searching for it I came across gtk_widget_set_size_request which has two parameters in pixels for width and height. Probably the screen's dpi-value can be read somehow, so 50.0*dpi/2.54 would be a proper minimum width, 8.0*dpi/2.54 would be a proper minimum height. Unfortunately I am not experienced enough to know where this call has to be placed
(In reply to Adalbert Hanßen from comment #7) > BTW: #125543 also might be another candidate for duplicateship! I came > across it searching how one would have to call SetMinOutputSizePixel to > implement a minimum width of 5 cm as I proposed above. Unfortunately I found > no description for SetMinOutputSizePixel. But searching for it I came across > gtk_widget_set_size_request which has two parameters in pixels for width and > height. Probably the screen's dpi-value can be read somehow, so > 50.0*dpi/2.54 would be a proper minimum width, 8.0*dpi/2.54 would be a > proper minimum height. Unfortunately I am not experienced enough to know > where this call has to be placed Thanks, Adalbert. Please feel free to add your comment to bug 97894 for more visibility, and possibly some help / code pointers from other devs. A patch would be very welcome, even if it needs some refining with other people's help!