Bug 60494 - UI: Expect minimum split pane height to depend on row 1 text line height and zoom level (now min 2 rows at 66%)
Summary: UI: Expect minimum split pane height to depend on row 1 text line height and ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.5.2 release
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Cell-Freeze
  Show dependency treegraph
 
Reported: 2013-02-08 14:30 UTC by gekacheka
Modified: 2023-12-09 08:22 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Libre Office Calc 4.0.2.2 cannot make 1 frozen row at 65% (18.57 KB, image/png)
2013-04-10 03:21 UTC, gekacheka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gekacheka 2013-02-08 14:30:23 UTC
Problem description: 

If font size 10 is zoomed to 66% (or font size reduced to 7 at 100%), the minimum height split pane is two rows rather than one row (column headers).


A. Tried split after zoom 66%

Steps to reproduce:
1. New Spreadsheet (default font size is 10)
2. Reduce zoom level to 66% (lower right slider)
3. Add 1 column header row and some data under them
4. Drag split pane button (above right scroll bar) and
   try to split pane so top pane shows only column headers.

Current behavior:

Minimum top pane height is 2 rows.

Expected behavior:

Minimum top pane height is height of a text line in row 1 (at current zoom level and font).


B. Tried split after reduce font size to 7

Changing the font size to 7 at 100% zoom does not not help, still shows a minimum of two rows in the top header pane.

5. return zoom to 100%
6. click in a cell, type control-A to select all cells
7. Reduce font size from 10 to 7.
8. Try to reduce split pane height to 1 row.

Current Behavior:

Minimum height is 2 rows.

Expected Behavior:

Minimum height is 1 row at current font level.


C. Tried with double click split button

Double click pane splitter removes split pane.
So I expected that double clicking split button (above right scroll bar) would add a split pane, maybe at minimum height.

1. new sheet
2. double click split button (above right scroll bar)

Current Behavior:

Nothing happens

Expected Behavior:

Split sheet, maybe at minimum height.

It did not split pane (on a new sheet).  I guess it remembers previous split. If there is no previous split, then maybe the default could be 1 row split instead of no split.

p.s. Thank you for your work!
Comment 1 BorosIstvan 2013-04-08 10:53:13 UTC
Can you attach a file or a screen please. i try reproduce your problem in 4.0.2.2 and the dealy master but i can't. I want see what happens in your LO.
Comment 2 gekacheka 2013-04-10 03:21:33 UTC
Created attachment 77716 [details]
Libre Office Calc 4.0.2.2 cannot make 1 frozen row at 65%

Thanks for looking at this.   I just tried again with 4.0.2.2.
Clicked the zoom '-' button 4 times to get 65%.
It looks like now if I drag down to 2 rows, then it always snaps to
an integer number of rows (2 rows, 3 rows, etc.) 
and I cannot drag it up to 1 row.
But if I start over from no frozen rows and drag slowly, 
I may be able to get it to drag to 1.3 rows or so (not an integer), 
but not 1 row.  It is not obvious why the behavior is different
(continuous fractional number of rows vs. snap to integer row sizes).
Comment 3 Jean-Baptiste Faure 2013-04-17 08:51:15 UTC
Please, do not report several different problem in the same bug report, instead file a new bug report for each one.

I do not reproduce the problem A with LibreOffice 4.0.4.0+ under Ubuntu 12.04 x86-64 (Build ID: 243df043a4ee78509049c5fd5a9f72cce46b029), nor with current release 4.0.2.2  (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3)

Best regards. JBF
Comment 4 Joel Madero 2013-04-17 15:56:01 UTC
I have been able to confirm the issue on:
Version 3.6.5.2 
Platform: Bodhi Linux 2.2 x64
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
As I've been able to confirm this problem on an earlier release I am changing the version number as version is the earliest version that we can confirm the bug, we use comments to say that the bug exists in newer versions as well.

Marking as:

New (confirmed)
Minor - does not prevent high quality work, may slow it down just a little (but probably not even this)
Low - default for minor bugs, seems appropriat

Keywords - 

Whiteboard Status - ProposedEasyHack

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Comment 5 ign_christian 2013-05-29 14:29:15 UTC
I can confirm that all problems A,B,C on the Description not reproducible using LO 4.0.3.3 (Win7 32bit)

Perhaps problems has been fixed. Change status to RESOLVED WORKSFORME ?
Comment 6 Joel Madero 2013-05-29 15:39:41 UTC
Per comment marking as WFM.

@gekacheka - if this is not the case on latest stable please mark bug as UNCONFIRMED again (probably need to mark as NEEDINFO then UNCONFIRMED due to limits with bug tracker) and provide any additional info requested.

Thanks all!
Comment 7 gekacheka 2013-06-01 02:48:00 UTC
As of Version 4.0.3.3 (Build ID: 0eaa50a932c8f2199a615e1eb30f7ac74279539)
it is still behaving as originally reported. 
Windows XP sp3, 1280x800 screen, 96dpi, font is Arial 10.
Comment 8 ign_christian 2013-06-01 05:00:58 UTC
still not happen on LO 4.0.4.1 (Win7 32bit), 1280x768 screen, 96dpi

spesific to XP?
Comment 9 Joel Madero 2014-02-27 22:57:39 UTC
In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval.

Thank you and apologies for the noise
Comment 10 Buovjaga 2014-10-28 12:53:33 UTC
I reproduce A. Don't repro B.

Win 7 64-bit dev build Version: 4.4.0.0.alpha1+
Build ID: 14a2cfc27f86112469f2a2252bdc154ad8d3219f
TinderBox: Win-x86@42, Branch:master, Time: 2014-10-28_04:51:26
Comment 11 Robinson Tryon (qubit) 2015-12-13 11:21:23 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2017-03-06 14:05:33 UTC Comment hidden (obsolete)
Comment 13 Thomas Lendo 2018-11-06 19:59:50 UTC
Issue A is still reproducible. If zoom level is small, it isn't possible to have only one row in the top split view.

Issue C and B not reproducible.

Version: 6.2.0.0.alpha1+
Build ID: fff34169fa912ad5096f1652172ea2455e5cb4d3
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: de-DE (de_DE.UTF-8); Calc: threaded
Comment 14 QA Administrators 2019-11-07 03:33:19 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2021-11-17 05:12:24 UTC Comment hidden (obsolete)
Comment 16 QA Administrators 2023-11-18 03:13:02 UTC Comment hidden (obsolete)
Comment 17 gekacheka 2023-12-09 01:52:23 UTC
In 7.6.4.1, is possible to get 1 row split using steps A or B.  It may take a little mouse dragging to get the height just right to show only 1 row, but it is possible.

Version: 7.6.4.1 (X86_64) / LibreOffice Community
Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded