Bug 116609 - TABLE PROPERTIES: Overhauling column width changes
Summary: TABLE PROPERTIES: Overhauling column width changes
Status: RESOLVED DUPLICATE of bug 113960
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Writer-Table-Properties-Dialog
  Show dependency treegraph
Reported: 2018-03-24 18:16 UTC by Frank Brütting
Modified: 2018-03-27 06:53 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Frank Brütting 2018-03-24 18:16:24 UTC
Imagine you have a quite big table, that fills the whole page width. Now you want to enlarge the first column, and therefore need to make column 8 smaller.

So if you go to the table settings window and increase the size of the first column, you will experience, that for some inexplicable reason, column two gets scaled down…?! [Facepalm #1!] Well, I covered that in #113960. So you need to check “Adapt table width” every time you want to modify column widths. But you won’t be able to do that immediately, as you always have to first go to the “Table” tab and set “Alignment = center” – every time…?! [Facepalm #2!] Well… OK, let’s skip that. But still consider, that those required actions conceptually belong to this bug I’m currently describing!

Now you have set “Alignment = center” and checked “Adapt table width” and try to enlarge column one. You will see that this even now isn’t possible – instead you have to first reduce the size of another column for being able to increase another one. [Facepalm #3!]

This whole thing is very tedious, as the column width list in the “Columns” tab of the table settings is very ugly. There is a whole lot of unused space below the column width boxes – still, you have to “scroll” weirdly horizontally for being able to modify columns #(>6). [Facepalm #4!] And for also some inexplicable reason, we aren’t able to enlarge that settings window. [Facepalm #5!]

So we have to first scroll to column 8, scale that down and then scroll back to column 1 and THEN you’re able to scale that up. [Facepalm #6!]

Does that really need to be that complicated? I TOTALLY miss a concept for settings here.

One thing that would improve that ugly experience would be, to allow a table’s width to be larger than possible while residing in the settings window. You then just need to highlight that constraint mismatch (maybe via red font message) and grey out the OK button for changes not being able to take effect. Then we at least could adapt each column in ascending order, without having to reorder that process to “first make specific columns smaller, then make the rest larger”.

In total, please overhaul that process completely, is this really is kind of broken, devastating and daunting.

Steps to Reproduce:

Actual Results:  

Expected Results:

Reproducible: Always

User Profile Reset: No

Additional Info:

User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Comment 1 Heiko Tietze 2018-03-26 07:25:40 UTC
How is that ticket different from bug 113960, which you are pushing?
Comment 2 Frank Brütting 2018-03-26 23:07:47 UTC
My other bug is about changes for one column affecting other columns. This bug in contrast is about the way table settings are implemented, because that’s a quite tedious task. I for example like to propose, that column width changes should be allowed even if the table would grow beyond the page width – but just temporarily, for as long the user resides in that settings dialog (thus the “apply” button should be greyed out then).

Any sorry for my language, I just got pretty pissed after having modified quite some tables… :/
Comment 3 Heiko Tietze 2018-03-27 06:53:05 UTC
Sorry, I don't see the difference. It's all about total table width on resizing. And while I fully understand that you are upset, the pushy tone wont help. Developers need short and clear instructions.

PS: I would ask for means to equally distribute columns on resizing in addition to bug 113960.

*** This bug has been marked as a duplicate of bug 113960 ***