Description: If several columns (applies equally to rows) are selected and the width of the selection is adjusted with the mouse, the width of the entire selection should correspond to the end position of the mouse pointer. This would make resizing more convenient (what you see is what you get). What actually happens: Only the size of the most right column is adjusted and then applied to all the columns. Steps to Reproduce: 1. Make column A one unit (e.g. centimeters) wide and column B two units wide 2. select both column A and B 3. By dragging the right edge of the column B, adjust the width of the selection so that the whole selection is four units wide before you release the mouse button 4. release the mouse button Actual Results: Both column A and B are 3 units wide. The right edge of column B jumps to the right after the mouse button is released Expected Results: The right edge of column B should stay where it was dragged with the mouse. The widths of column A and B add up to 4 units. Each column should be adjusted proportional to its previous size, i.e. column A should stay half as wide as column B. expected new widths: 1.33 units and 2.66 units Reproducible: Always User Profile Reset: No Additional Info: -
Also, the tool tip that show the width before you release the mouse button, should show the size of the whole selection, not the size of a single column.
The behaviour was the same already in 3.5. Adding UX team. A bit related: bug 142477.
It's a convenience feature that resizing one column is applied to all selected (any, not just the right-most). Assuming we implement the suggested variant, eg. enabled per modifier key, how would the procedure deal with some other column/row than the last? For example, you select A:E and resize on C.
(In reply to Heiko Tietze from comment #3) > It's a convenience feature that resizing one column is applied to all > selected (any, not just the right-most). Yes and it should stay that way. How I read Henrik's report, he means that the total width you set (by dragging) should be divided over all selected columns. That's an interesting design question :) Let me note that - sometimes I recognize the behavior as odd, but usually not; (no idea why) - that the tooltip while dragging clearly shows the new size; - Ctrl-Z is still one of my best friends ;)
Thanks for having a look at this. My most typical use case is this: I have a table and want to print it or export to PDF and want it to take up the whole width of a single page. The columns do not have the same widths because some contain labels and other contain single digits. I want to resize SOME of the columns so the width of the table matches the width of the page. Small columns should stay small and wide columns should stay wide. But most of all I would like to see in advance (before the mouse button is released) how wide the whole selection will be afterwards. (In reply to Heiko Tietze from comment #3) > Assuming we implement the suggested > variant, eg. enabled per modifier key, how would the procedure deal with > some other column/row than the last? For example, you select A:E and resize > on C. What would feel most natural for me would be: The right edge of C would stay where you release the mouse button, D:E will resize by the same factor. In peudo-code it should be like this: void handleMousePointerRelease() { int difference = mousePointer.xPostionNow - mousePointer.xPositionBefore; int oldWidth = 0; foreach (col in currentTable.getAllColumns()) { if (col.right > xStart) { break; } if (col.isSelected) { oldWidth += col.width; } } double factor = (oldWidth + difference) / oldWidth; foreach (col in currentTable.getAllColumns()) { if (col.isSelected) { col.width *= factor; } } }
We discussed the topic in the design meeting. Microsoft Excel, at least, behaves like LibreOffice Calc and shows the width of the column being resized and applies this to all selected ending up in a much larger total size. We should keep this familiar behavior and add the new functionality as an alternative, eg. when ctrl/cmd is pressed.