Created attachment 185534 [details] screen shots Cannot change cell size easily in Libre Office 7.4.5, no issue in 7.3.7, see attachment
Believe this is a result of work on bug 99708 to provide per-document height for the Formula bar's input window. At 7.4 the input window toggle "arrow" is now the only way to expose the default 6 line height of the input window. It can't be dragged larger and there is no UI means to set the value (a range of 1 - 25 lines). The "FormulaBarHeight" default value of 6 lines is written out to document archive. Some means to adjust when using the UI would be helpful.
(In reply to V Stuart Foote from comment #1) > At 7.4 the input window toggle "arrow" is now the only way to expose the > default 6 line height of the input window. At least on Windows, we can (7.4.5.1 ATM) toggle the box/window, and/or we can also modify the size of the box/window. What we cannot do is change the font type and size within it (i.e. a different matter), but the window box _can_ be modified (independent of the "toggle").
(In reply to ady from comment #2) > (In reply to V Stuart Foote from comment #1) > > At 7.4 the input window toggle "arrow" is now the only way to expose the > > default 6 line height of the input window. > > At least on Windows, we can (7.4.5.1 ATM) toggle the box/window, and/or we > can also modify the size of the box/window. What we cannot do is change the > font type and size within it (i.e. a different matter), but the window box > _can_ be modified (independent of the "toggle"). Oh snap, you are right! The mouse "grab" target on the top edge of the column header below the input bar is *hard* to point at. Pointing at the edge but to the left of the Formula bar helps. But it can be picked and the inputwin of the Formula bar still dragged larger. Or can use the toggle arrow for multi-line mode enabled.
Created attachment 185537 [details] UI mouse drag of Formula bar input win height -- at 7.5.1.1 similar results on trunk against 7.6, but IIRC there was a Options or Expert config setting for the number of lines that would be shown on toggle.
No issue with qt5 but on resizing it maximizes this part and I'm never able to make it smaller again (unless to collapse). Gen and gtk3 work more or less acceptable but seem to be cut off. I suspect the input to be maximized like for qt/gen but covered. Besides fixing the bugs we need some splitter to indicate the sizing capability. Szymon and Caolan worked recently on the formula bar, and Thorsten before. Any idea?
(In reply to Heiko Tietze from comment #5) > Besides fixing the bugs we need some splitter to indicate the sizing > capability. FWIW, on Windows, there is one. It might not be the most evident, but there is one. The following is not the most efficient way to find it (i.e. once you know it is there, you need less steps), but it is the easiest way I can describe it (for common users too, not just for expert devs): 1. New Calc document, with formula bar collapsed to its minimum height. At this point, the mouse tool tip on the arrow to collapse / expand the input box window says "Expand Formula Bar". 2. Click once on the arrow to expand the collapsed input box window (on the right side of the formula bar). Without moving the mouse, the tool tip now says "Collapse Formula Bar", and the input box window is expanded. 3. With the mouse still located (but not pressed) over the same arrow (used in step 2 above), move the mouse straight down vertically, until it reaches the handler line located over the "vertical scrolling arrow" located over the vertical scroll bar. The mouse pointer will change to a vertical slim double arrow. 4. At this point, click (left) and hold to drag the mouse, either down or up. 5. Release the mouse at the desired point/height. Note that this works when approaching the handler from the top-down. When approaching the same handler from the bottom-up, the "click (left) and hold to drag" action will split the main area window vertically. IOW, the resulting action depends on whether you approach the handler from the top-down, or from the bottom-up. The advantage is that it saves the need of 2 separate handlers / space on screen.
I don't see this as an enhancement request, but rather a regression that started with 7.4. Tested with gtk3 VCL: In 7.3, I can resize by drag and drop however I want. Version: 7.3.7.2 / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded In 7.4.5 and 7.5.0.3, I can still drag but I have to do it from somewhere below the edge of the area. There is to much space between the column headers and the edge of the input area. Version: 7.4.5.1 / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Finally, in a recent master build, I can't reduce the size by dragging after having expanded it, and the edge overlaps with the column headers. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c41e872ed248f804249ecf4d65c4afc2e426e329 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(In reply to Stéphane Guillou (stragu) from comment #7) > Finally, in a recent master build, I can't reduce the size by dragging after > having expanded it, and the edge overlaps with the column headers. > > Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: c41e872ed248f804249ecf4d65c4afc2e426e329 > CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 > Locale: en-AU (en_AU.UTF-8); UI: en-US > Calc: threaded Same on Windows (can't reduce window box size after it was expanded): Is OK in: Version: 7.4.5.1 (x64) / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL But KO in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: dbbfcb7e098c1c16f932785ef62ef7d3d819ad1a CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL threaded
The vertical resize "arrow" shows with mouse pointer on the edge to the left of the exposed multiline Formula bar input window, just as shown in attachment 185337 [details] for 7.5.1.1 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 74dc2ac66f0130bcd77cf1bbe417b22865beb067 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to V Stuart Foote from comment #9) > The vertical resize "arrow" shows with mouse pointer on the edge to the left > of the exposed multiline Formula bar input window, just as shown in > attachment 185337 [details] for 7.5.1.1 In my case, the arrow is there on the left-side too, but it actually works on 7.4.5 while it fails on 7.6. alpha+ on that same left-side. It still works on the right-side. The question now is: is this intentional, or there is sth wrong on the left-side (which stopped working in 7.6. alpha+).
(In reply to ady from comment #10) > (In reply to V Stuart Foote from comment #9) > > The vertical resize "arrow" shows with mouse pointer on the edge to the left > > of the exposed multiline Formula bar input window, just as shown in > > attachment 185337 [details] for 7.5.1.1 > > In my case, the arrow is there on the left-side too, but it actually works > on 7.4.5 while it fails on 7.6. alpha+ on that same left-side. It still > works on the right-side. The question now is: is this intentional, or there > is sth wrong on the left-side (which stopped working in 7.6. alpha+). Weird, bcz it works fine to the left in 7.6.0 n(74dc2ac6) on Windows 10 (22H2)
(In reply to V Stuart Foote from comment #11) > Weird, bcz it works fine to the left in 7.6.0 n(74dc2ac6) on Windows 10 > (22H2) Win 10, but 21H2. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: dbbfcb7e098c1c16f932785ef62ef7d3d819ad1a CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL threaded On the left side, the "split main window" still works, but once I split the main window, it is clear then that the handle to shrink the formula window box doesn't "exist" anymore; the double arrow is not there. On the _left-side_: 1. Drag down to expand the formula window box. 2. Drag down to split the main area. 3. The initial handle to resize the formula window box is not there anymore; there is no double vertical arrow. I can shrink it with the toggle arrow, or by dragging the right-side (where there is not visual clue, other than the double vertical arrow, which appears only because I am looking for it).
(In reply to ady from comment #12) > (In reply to V Stuart Foote from comment #11) > > Weird, bcz it works fine to the left in 7.6.0 n(74dc2ac6) on Windows 10 > > (22H2) > > Win 10, but 21H2. > Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: dbbfcb7e098c1c16f932785ef62ef7d3d819ad1a > CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: > win > Locale: en-US (es_AR); UI: en-US > Calc: CL threaded Sorry. My apologies. The following is of course of the *right-side*, where the scroll bar is located. right <--> left. > > On the right side, the "split main window" still works, but once I split the > main window, it is clear then that the handle to shrink the formula window > box doesn't "exist" anymore; the double arrow is not there. > > On the _right-side_: > 1. Drag down to expand the formula window box. > 2. Drag down to split the main area. > 3. The initial handle to resize the formula window box is not there anymore; > there is no double vertical arrow. > > I can shrink it with the toggle arrow, or by dragging the left-side (where > there is not visual clue, other than the double vertical arrow, which > appears only because I am looking for it). Apologies again.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3b279889daa9c37fe91663d16dd2d8c5938cc0d5 Related: tdf#153784 margin_bottom is a cnp nonsense, should be margin_end It will be available in 7.6.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.
I think what I see is: a) the drag area to resize is the bottom 4 pixels of the toolbar b) Initially there is 1 line and the edit is vertically centered in the toolbar c) when expanded then the height of the text area for e.g. 6 lines is correctly calculated and the edit resized and the toolbar resized to fit. But the edit top position remains at its initial position and that behavior isn't factored in to the size of the toolbar so the edit extends over the 4 pixel drag area, and maybe depending on platform/desktop over the column headers a little
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9a0710bb05b6b9bc0873dbc2d2dc5eb40ce02eba tdf#153784 account for initial vertical offset when toggled into multiline It will be available in 7.6.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.
hopefully that is the substantive issue, backport to 7-5 in gerrit and maybe 7-4 if things work out
Works for gtk3 but kf5 expands to the maximum and does not allow shrinking per mouse.
That was already the case right, this didn't make things any better for kf5, but didn't cause it?
(In reply to Caolán McNamara from comment #19) > That was already the case right, this didn't make things any better for kf5, > but didn't cause it? Yes, was like this before.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/cb1eed1cbb2b33d5d8244bfcc075de4cd61a01f1 Related: tdf#153784 margin_bottom is a cnp nonsense, should be margin_end It will be available in 7.5.2. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/dbe36c47aa685ccdcfd05e5116348ace7b3bd68f Related: tdf#153784 margin_bottom is a cnp nonsense, should be margin_end It will be available in 7.4.7. 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.
With Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 46e74a8bf03c06776cb144418206db7c4b843b41 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded The Formula Bar's inputwin is now fully exposed on its bottom edge. But seems that the "handle" for the 'Split Window' is really not part of the inputwin. Though it does drag expand the inputwin if keeping mouse pointer on the scrollbar or over the inputwin while dragging downward. But once crossing onto the sheet, the split on the sheet asserts and the handle no longer works for the inputwin. Can't tell if the mixed is intentional, but it is a little awkward. And, if in Split Window mode the Formula bar inputwin can still be resized, but have to grab the top edge of the sheet table. Can clear via main menu View -> "Split Window" toggle to restore the "handle" for use with the inputwin. So its a feature? =-note-= @Caolán, there is a minor positioning glitch still with the inputwin, noticeable from main menu View -> Formula Bar toggle. On toggle viewable, the inputwin is dropped below the top edge of the Formula Bar and not aligned with the other elements. Cycling the 'Expand Formula Bar' 'Collapse Formula Bar' selection triangle corrects placement. New BZ issue for it?
(In reply to V Stuart Foote from comment #23) > But seems that the "handle" for the 'Split Window' is really not part of the > inputwin. If you are talking about the right-side thick line located over the up arrow for the scroll bar of the main working area, it is still as I described before: * when approaching the handle from the top-down, when the mouse pointer gets to be a double-arrow, grab it and drag it > that's the formula bar input box window. * when approaching the same handle from the bottom-up, when the mouse pointer gets to be a double-arrow, grab it and drag it > that's the split window for the main working area. It works when it is all "compacted", and when are separated. Having said that, when approaching it from the top-down, if I continue just a little bit, while the pointer still is displayed as double-arrow, and grab it then, the inputwin does not move, nor the split main area. It is as if I grabbed it "just in the middle", not in the top and not in the bottom of the handle. I can still recover: I release the mouse, move up and approach the handle again, eventually successfully grabbing it and changing the height of the input box window. Now, when grabbing by the bottom-middle of the input window, especially when reducing its height, it looks as if the bottom line of the inputwin is located higher than the handle (when the double-arrow mouse pointer shows up); the mouse pointer changes when it is located closer to the top of the column's headers, rather than where the bottom line of the inputwin is. When the inputwin is one-line only, there is no gap between the column headers and the inputwin's bottom. If I make the inputwin use more than one line (or toggle it), then there is a gap between them. In order to change the height of the inputwin from that position, I have to grab the top of the column headers, rather than the bottom of the inputwin. Version: 7.4.5.1 (x64) / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL Built 2023.03.02
Created attachment 185706 [details] one cell flat ODS with a long text fill and inputwin toggled expanded opening with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 46e74a8bf03c06776cb144418206db7c4b843b41 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded the formula bar inputwin shows dropped, and clipped on its bottom edge.
Created attachment 185707 [details] clip of issue opening attachment 185706 [details] The Formula Bar inputwin is shifted down and clipped on the bottom on opening fods/ods with FormulaBar's height expanded.
Sorry, sent prematurely. The above are all descriptions in 7.4.5. The gap is no longer in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 46e74a8bf03c06776cb144418206db7c4b843b41 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL threaded built 2023.03.02 The description of the right-side handle however is still as I just described in comment 24. Now I have finished the report. Sorry again for the premature sent of comment 24.
(In reply to ady from comment #24) Sorry, but the following was not supposed to be sent like that: > Version: 7.4.5.1 (x64) / LibreOffice Community > Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f > CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: default; VCL: win > Locale: en-US (es_AR); UI: en-US > Calc: CL > Built 2023.03.02 Version 7.4.5 was for the first description. 7.6.alpha+ built today, as seen in comment 27 was with the diff., as described in said comment 27.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/8fd61209c9aede44b30f74d8d630236f79504a5e tdf#153784 account for initial vertical offset when toggled into multiline It will be available in 7.5.2. 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.
(In reply to Commit Notification from comment #29) > tdf#153784 account for initial vertical offset when toggled into multiline > > It will be available in 7.5.2. Would it be also available for 7.4.7?
Back to resolved fixed, remaining to bug 154042 for opening a sheet that had been saved with Formula bar expanded.
(In reply to Heiko Tietze from comment #20) > (In reply to Caolán McNamara from comment #19) > > That was already the case right, this didn't make things any better for kf5, > > but didn't cause it? > > Yes, was like this before. This looks like another regression from commit afc828b9833b7a612369e95606ba56d41ef2c369 Author: Jan-Marek Glogowski Date: Sat May 28 23:47:21 2022 +0200 VCL expect correct frame size for native menubars and works fine for me with kf5 and a local revert of the above commit on top of master as of 0484a9a3f5e2ecb678f6fb41bbb251529e89c00d.
*** Bug 154403 has been marked as a duplicate of this bug. ***
(In reply to Michael Weghorn from comment #32) > (In reply to Heiko Tietze from comment #20) > > (In reply to Caolán McNamara from comment #19) > > > That was already the case right, this didn't make things any better for kf5, > > > but didn't cause it? > > > > Yes, was like this before. > > This looks like another regression from > > commit afc828b9833b7a612369e95606ba56d41ef2c369 > Author: Jan-Marek Glogowski > Date: Sat May 28 23:47:21 2022 +0200 > > VCL expect correct frame size for native menubars > > and works fine for me with kf5 and a local revert of the above commit on top > of master as of 0484a9a3f5e2ecb678f6fb41bbb251529e89c00d. This revert is now in master, and resizing works for me again for kf5 as well with that in place: commit f51b220b953ec71fb742f799fbe645a93cf3d944 Author: Michael Weghorn Date: Fri Mar 24 08:06:56 2023 +0100 tdf#149805 tdf#151677 tdf#152217 tdf#154043 tdf#153458 tdf#153800 Revert "VCL expect ... correct frame size for native menubars"
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/c38d91abf7e719e61a51798a7abddc81ba9ff9a9 tdf#153784 account for initial vertical offset when toggled into multiline It will be available in 7.4.7. 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.