Created attachment 143533 [details]
Bibisect log

Bisected to
author	Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>	2015-05-07 14:18:37 +0900
committer	Jan Holesovsky <kendy@collabora.com>	2015-05-07 09:57:50 +0200
commit dca01def7885ad69cf66edd75cf8207a5adb64f9 (patch)
tree f3b43717ab058b677c68614bcb2953beb7c7d1a0
parent 7a11ec1992bf877f42edce8d1d930c5b00bd3d48 (diff)
refactor ListBox/ComboBox to use RenderContext

I don't get the point. If the width AND height is too small for the context an overflow arrow is indicated. If What behavior do you expect? Could you provide screenshots please?

Created attachment 143535 [details]
Screenshot LibO 4.4.7.2

@Telesto: Thanks for the screenshot. Do you mean that LibO 4.4.7.2 automatically increases the hight after reducing the width? If yes, I am not sure if this behavior is the "better" one.
You need just to double-click the row divider line on the left side to restore a best fit row height.


The behavior of recent LibO build (I have tested 6.0.3.2) - NOT to adjust the row height automatically after changing the column width - seems reasonable to me. In addition I found that MS Excel 2013.

... behaves identical.

Set keyword needsUXEval. I vote for keeping the behavior as it is at the moment (LibreOffice 6).

(In reply to OfficeUser from comment #4)
> @Telesto: Thanks for the screenshot. Do you mean that LibO 4.4.7.2
> automatically increases the hight after reducing the width? If yes, I am not
> sure if this behavior is the "better" one.
> You need just to double-click the row divider line on the left side to
> restore a best fit row height.


Do you mean that LibO 4.4.7.2 automatically increases the hight after reducing the width
-> Yes

> The behavior of recent LibO build (I have tested 6.0.3.2) - NOT to adjust
> the row height automatically after changing the column width - seems
> reasonable to me. In addition I found that MS Excel 2013.

Yes, indeed. However the height of the cell gets adjusted after 'entering' (A1) in Excel, but not in Calc. Calc changes the height after some edit in A1

I don't see an issue here--cell/row height direct formatting should be detached from "Wrap text automatically" Cell formatting of the style.

Apply the "Optimal Row Height" direct formatting from Format -> Row -> Optimal Height or the context menu.  Likewise for direct formatting of the Column width from Format or context menu. 

Believe this is working correctly.

I agree with Stuart.


Further reasons are:

1. If the user clicks into a cell to "enter" it he normally does NOT intent a height adjust.

2. An easy hight adjust can be triggered by double-clicking the row divider line on the left side (at the row buttons).

To start with: I reported this bug because of the change in behaviour, not because I care about the outcome. So, if this is what we want, it's fine.

However, the current behaviour is still inconsistent in any case (or lacking a proper explanation). 

@ Stuart
Cell/row height direct formatting should be detached from "Wrap text automatically" Cell formatting of the style.

-> this isn't truly the case at the moment. cell/row height adjustment happen quite often with "Wrap text automatically" enabled

Situation 1
1. Format Cell -> Alignment tab -> Wrap text automatically
2. Start typing to get a few lines/rows of text -> Cell Height will be adjusted automatically

Situation 2
1. Reduce the column width
2. Enter the cell with multiline content and make an adjustment (or apply ing a autocorrection) -> cell height will be adjusted

Situation 3
1. Reduce the column width
2. Double-clicking the row divider line on the left side (at the row buttons). -> cell height will be adjusted

And it's broken in this case
1. Instead of reducing, increase the column width (from situation 1) -> the row height won't adjust (which is the opposite of my initial report)
2. It's only correct with step 2 of situation 2 and 3. And this isn't obvious. 

---

Possible solutions
1. Detach cell height from "Wrap text automatically" in all cases
2. Go back to the initial situation of LibO 4.4.7.2

Some other bug reports related to wrapping & column height. 
bug 32950 
bug 57519 
bug 65200

Duplucate of Bug 57519?

(In reply to V Stuart Foote from comment #8)
> I don't see an issue here--cell/row height direct formatting should be
> detached from "Wrap text automatically" Cell formatting of the style.
> 
> Apply the "Optimal Row Height" direct formatting from Format -> Row ->
> Optimal Height or the context menu.  Likewise for direct formatting of the
> Column width from Format or context menu. 

I don't get how they could be detached as automatic increasing of height is the main point of wrapping. Or do you propose to remove the height increasing functionality entirely, so the text would wrap horizontally when typing, but go out of sight vertically while displaying the red triangle?

This was not discussed in a design team meeting, so I don't understand the dance with the keyword and CC. If this is decided to be notabug and the behaviour even further changed, it is such a significant change that it has to be dealt with in a meeting. There is a large body of users that considers this to be a bug since years (in AskLibO, BZ...).

If this is decided to be notabug, then all the other reports need to be analysed and closed if needed (at a minimum bug 57519).

(In reply to Buovjaga from comment #13)
> (In reply to V Stuart Foote from comment #8)
> > I don't see an issue here--cell/row height direct formatting should be
> > detached from "Wrap text automatically" Cell formatting of the style.
> > 
> > Apply the "Optimal Row Height" direct formatting from Format -> Row ->
> > Optimal Height or the context menu.  Likewise for direct formatting of the
> > Column width from Format or context menu. 
> 
> I don't get how they could be detached as automatic increasing of height is
> the main point of wrapping. Or do you propose to remove the height
> increasing functionality entirely, so the text would wrap horizontally when
> typing, but go out of sight vertically while displaying the red triangle?
> 

Testing sample document with current master/6.2.0, the documents sheet presents a "default" Cell Style without "Wrap text automatically" enabled.

Meaning the example cell *is* under Direct Formatting to wrap its text.

Modify the default style to include the wrap text automatically, and apply it (the Update Style on the content panel).  Alignment/wrap within the cells is picked up from the style as opposed to the direct formatting.

And, with the change to Cell Style, all other cells being entered will wrap within their Column width as set, shifting height--the desired behavior.

Beyond the row height response when the Sytle to wrap text is enabled, IIUC controlling column width and row height is not done by any cell style and so any change to set "Optimal Height / Optimal Width" are Direct Formatting of the selected cells or columns/rows. 

So again, I don't see an issue here (other than our on going challenge of educating users (and QA members) about styles vs direct formatting)--but I could be wrong.

I've no concern with taking this back through UX-Advise, but the behavior seems correct IMHO.

(In reply to V Stuart Foote from comment #14)
> So again, I don't see an issue here (other than our on going challenge of
> educating users (and QA members) about styles vs direct formatting)--but I
> could be wrong.

I tried wrapping through Default style, but it behaves just like direct formatting. I decrease column width and the text is cropped in the vertical axis. So I'm not sure how this is about styles vs. direct formatting education.

This is rather about user expectations concerning the automatic applying of direct formatting: why is the automated height increase tied to inputting content, but not to changing of column width?

I agree with Stuart and Norbert on WFM. Try with blind text from Writer (or any other lengthy passage of text) in older version to see how odd the increase of row height is. 

(In reply to Buovjaga from comment #15)
> I tried wrapping through Default style...

Sounds like a different topic; Default is defined with wrap off and I think typical text is short like two words and must not change the vertical alignment over multiple cells, which happens after wrapping. In any way we will make some people unhappy.

Correction: cell height is only kept when defined by the user. Meaning when you paste text into a new document without changing the row height and wrap it grows over the total size. If the height has been defined before this value is kept. It's the same in 5.2.7 and 6.1 (and works for me).

*** Bug 57519 has been marked as a duplicate of this bug. ***

I tested with Excel 2013 and there the behaviour is:
1) Change the width of a wrapped cell, text gets cropped vertically (like with LibO)
2) Double-click to the cell from step 1) and click away: the height adapts to display the full text (LibO does not do this)

I tried to bisect when the behaviour requested by Telesto to be restored was originally introduced. I used 42max, but unfortunately I had to do lots of skipping. The final repo commit suspects were these and I checked them all, but none seemed relevant:
 48e32d82ffcda002119406d63883ea9ba6d8d247 db5c1d100da992d2e0d5a136bc088ca950df21f0 879f76934acd213633a14c0c3159aa37d257ec3e ae365233a4aa760e2b5d928613499cb99bbc32a6 2a78305e74a6ef4264be5403d584a841a4cba575 7425db1c97608fc3511860cffec844fe94e3881c 03cf2c53d4f2e8952398c8480e3ecd0c8e0ec556 9959d84880039df48d778723be0fb4a9e804b60a 50d75b98bfc24457d454ca4b2660808c43d4149f d74bfb2206795e5f4ddd8f37d004f452b1b0176c 38dad5aca61b3ae0ec1df3122ee00bbac7ee442e 677c6defa69745545cd85a2b25b28494959233fe 06271499c829a52c702c2c6dc8f99c2ec9c46fd3 7df4615583a9c8219e64918809b95a76a294359a 86cb6230299035756352ceb751a18a495356dca2

I also verified Telesto's bisect result from comment 1.

(In reply to Heiko Tietze from comment #16)
> I agree with Stuart and Norbert on WFM. Try with blind text from Writer (or
> any other lengthy passage of text) in older version to see how odd the
> increase of row height is.

I'm not sure I follow you - what older version? This has never worked in the ideal way of the user request in bug 57519.

> 
> (In reply to Buovjaga from comment #15)
> > I tried wrapping through Default style...
> 
> Sounds like a different topic; Default is defined with wrap off and I think
> typical text is short like two words and must not change the vertical
> alignment over multiple cells, which happens after wrapping. In any way we
> will make some people unhappy.

It's not a different topic. I tried it only because Stuart said this was somehow about direct formatting vs. styles (it was not). It sounds like you misunderstood somehow: nobody is requesting wrapping to be turned on by default.

(In reply to Heiko Tietze from comment #17)
> Correction: cell height is only kept when defined by the user. Meaning when
> you paste text into a new document without changing the row height and wrap
> it grows over the total size. If the height has been defined before this
> value is kept. It's the same in 5.2.7 and 6.1 (and works for me).

I don't know what this has to do with the topic.

*** Bug 122822 has been marked as a duplicate of this bug. ***