Download it now!
Bug 125543 - Calc window width and height resize to zero when unmaximizing
Summary: Calc window width and height resize to zero when unmaximizing
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval
: 136655 136662 (view as bug list)
Depends on:
Blocks: 75644 UI
  Show dependency treegraph
 
Reported: 2019-05-28 07:50 UTC by Heiko Tietze
Modified: 2021-05-23 12:58 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Tietze 2019-05-28 07:50:09 UTC
With a fresh profile, modules start maximized. That's not a good window size for large screens, so users have to resize. Doing this with Calc ends up in a tiny and hard to spot square (title bar only). We should a) use a default windows size according the OS and b) at least define a minimum size for Calc. AFAIR, it's not an issue for other modules.
Comment 1 Usama 2019-06-16 03:43:24 UTC
Hello Heiko,
Thank you for reporting this. I confirm it with:
Version: 6.3.0.0.alpha1+
Build ID: 77ae0abe21f672cf4b7d2e069f1d40d20edc49a7
CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-31_15:33:33
Locale: en-GB (en_GB.utf8); UI-Language: en-US
Calc: threaded

When minimizing it the window size changes to really tiny square around 12px.

Regarding starting as maximized I don't see it as an issue because the window size will be preserved for the next start. User will only have to change it once and most people don't have large screens.
Comment 2 Heiko Tietze 2019-06-27 08:04:30 UTC
Since Xisco requests input from UX, let's talk about. I work on a large super-wide screen where the modules are set to the maximum screen size - makes not much sense and I always resize first to ~1600x1200px, which is a 4/3 ratio. 

At least Windows has a application size policy with PreferredLaunchViewSize and we should follow this.

Last but not least we define as minimum required resolution 1280x768px in [1], that could also be taken into account.

Of course, the actual value has to be responsive to the resolution, and the default scaling should work with HiRes too (8k screens might come in some years). And we should maximize in case of very small screens.

[1] https://wiki.documentfoundation.org/Design/MenuBar
Comment 3 Heiko Tietze 2019-07-11 13:12:56 UTC
We discussed the topic in the design meeting and agreed on the proposal, considering a 16:9 ration, which is better suited for movies, and less space such as 50%, which would be too small. Any minimum value is an advantage over the zero size that might appear to users as broken (therefore I raise the importance).
Comment 4 Heiko Tietze 2019-07-15 11:22:32 UTC
SetMinOutputSizePixel() is implemented for include/vcl/syswindow and include/sfx2/dockwin but not include/vcl/window.hxx. And this function should receive the actual value from the OS/DE. Probably an easy hack for more experienced developers. Thanks jmux for the code pointers.
Comment 5 Xisco Faulí 2019-07-18 17:36:02 UTC
@Caolán, I thought you might be interested in this issue...
Comment 6 Caolán McNamara 2019-07-22 15:50:39 UTC
SetMinOutputSizePixel sets the minimum size below which a window cannot be shrunk, which is probably not whats wanted.
Comment 7 BogdanB 2020-08-31 09:24:09 UTC
In my case I had the window with 2 mm wight and 1 cm height. It is very hard to notice that this is a window. You can not edit in Calc in 0,02*1 cm... So, a default minim of 4 cm * 4 cm, or maybe 3*3 cm could be done. From my POV a 3*3 cm would be a minimum, else you can not see any cell in any file.
Comment 8 BogdanB 2020-09-11 04:08:56 UTC
*** Bug 136655 has been marked as a duplicate of this bug. ***
Comment 9 BogdanB 2020-09-11 19:42:17 UTC
*** Bug 136662 has been marked as a duplicate of this bug. ***
Comment 10 Jarosław Rafa 2021-02-08 16:28:16 UTC
I had this bug in a bit different scenario. I was running Calc maximized, and when I tried to import a CSV file by double-clicking on it, after going through the import dialog, my window minimized to a very small square.
This is reproduced everytime I run Calc maximized and import a CSV file via double-click.
If Calc was not maximized before import, there was no issue.
Comment 11 Jean-François Fortin Tam 2021-04-30 15:55:07 UTC
This bites me almost daily because whenever I open Calc by opening a document, and it opens maximized, and I un-maximize the window (Super+downarrow key in GNOME), it ends up becoming a 1x1 pixels (or something like that) micro window that is barely noticeable.

Non-technical users (like many people in my extended family, who don't know the keyboard shortcuts to un/maximimize) would be pretty flustered by that and will end up with a "broken" app practically speaking.

> SetMinOutputSizePixel sets the minimum size below which a window cannot be shrunk, which is probably not whats wanted.

Actually that's exactly what I would want, at least as the fallback for undefined states where the app can't figure out what the appropriate default size would be. Make it enforce a hard minimum of 600x400 at the very least.

Why would anyone ever want to have a LibreOffice Calc/Writer/etc. main window sized anywhere smaller than 640x480 pixels? It seems to me that it could safely be assumed to be the absolute minimum to which a main app window can no longer be shrunk, because it's no longer usable below that size (even the toolbars would eat half of the height). Even phones these days have at least 720px in one dimension or the other, and no VGA output that I know shrinks below 640x480 even in disaster scenarios.
Comment 12 Dan 2021-05-23 12:58:29 UTC
(In reply to Jean-François Fortin Tam from comment #11)
> This bites me almost daily because whenever I open Calc by opening a
> document, and it opens maximized, and I un-maximize the window
> (Super+downarrow key in GNOME), it ends up becoming a 1x1 pixels (or
> something like that) micro window that is barely noticeable.
> 
> Non-technical users (like many people in my extended family, who don't know
> the keyboard shortcuts to un/maximimize) would be pretty flustered by that
> and will end up with a "broken" app practically speaking.
> 
> > SetMinOutputSizePixel sets the minimum size below which a window cannot be shrunk, which is probably not whats wanted.
> 
> Actually that's exactly what I would want, at least as the fallback for
> undefined states where the app can't figure out what the appropriate default
> size would be. Make it enforce a hard minimum of 600x400 at the very least.
> 
> Why would anyone ever want to have a LibreOffice Calc/Writer/etc. main
> window sized anywhere smaller than 640x480 pixels? It seems to me that it
> could safely be assumed to be the absolute minimum to which a main app
> window can no longer be shrunk, because it's no longer usable below that
> size (even the toolbars would eat half of the height). Even phones these
> days have at least 720px in one dimension or the other, and no VGA output
> that I know shrinks below 640x480 even in disaster scenarios.

I'm also experiencing exactly the same issue, running KDE Neon. In fact, I cannot even find the 'pixel' on my display and need to force-close the app. It really is an absurd situation - clearly a bug and not a feature!