Created attachment 176315 [details] Current version of the Colum Width fialog The current UI of the Column Width dialog of the Table Properties dialog is problematic: 1. It is not clear what "adapt table width" does from reading its label. One cannot guess apriori that, in itself, it does nothin. and is actually a modifier on the action of other controls. Also "adapt table width" - adapt it to what maybe, something like "Change table width to track changes to column width settings". 2. The overall table size has no control in this dialog, not even a read-only display of the effects of other changes. 3. It is not clear what "adjust columns proportionally" does. When will columns be adjusted? What will change in proportion to what else? What proportional to what? 4. It is not clear what "remaining space" means. How does space "remain"? And what space is it which "remains? 5. The scrolling-among-individual-columns controls are idiosyncratic. They are also annoying, since you don't have a scroll bar among the lot of them; nor can you look one up by its index. 6. Pressing Tab when in the last currently-visible column -/+ box does not scroll one column further.
bug 129639 "Could Not Set Column Width in One Column Table" bug 139096 and bug 139109 with the same issue pointing to bug 114633 "Setting unevenly distributed columns sizes is hard and cumbersome the achieve using Table properties or set width" bug 116609 pointing to bug 113960 "Adapting table width by default" bug 100537 "Width and relative checkboxes disabled in Table dialog by default with automatic alignment" (resolved NAB) I suggest to have only one dialog for the UI redesign. "Adjust table width" is not so unclear, admittedly with some ugly dependencies like discussed in bug 145738, and we could also argue to read the help.
(In reply to Heiko Tietze from comment #1) > bug 129639 "Could Not Set Column Width in One Column Table" That one is about the size change not working, it's not a complaint about the UI layout; plus it's about a different dialog (Table context menu | Size | Column Width). > bug 139096 and bug 139109 with the same issue pointing to bug 114633 > "Setting unevenly distributed columns sizes is hard and cumbersome the > achieve using Table properties or set width" That (unclosed) bug it's not about the UI layout per se, but about the cascading effects of setting one column width on the others - which is not something I complained about here, although it is certainly frustrating and related to the UI choices. > bug 116609 pointing to bug 113960 "Adapting table width by default" No complaints about the size redistribution policy here. I'd say that's not even a related issue. Redistributing among the two neighbors is valid logic, and so is redistributing among all columns. > bug 100537 "Width and relative checkboxes disabled in Table dialog by > default with automatic alignment" (resolved NAB) I didn't complain about that; my concerns are with the Column Widths dialog _only_. > I suggest to have only one dialog for the UI redesign. Do you mean "only one bugzilla bug"? Or do you mean the same dialog reachable from Table Properties and from the context menu? > "Adjust table width" is not so unclear, admittedly with some ugly > dependencies like discussed in bug 145738, You've misquoted the label text (which I interpret as another indication of the problem with this setting). It's labeled "_adapt_ table width". _adjust_ table width would be just as bad: You only adjust something with a value from a continuous range, or at least a choice among many settings, while this is a checkbox - a binary choice. > and we could also argue to read the help. You know that saying, "patriotism is the refuge of the scoundrel" :-P ... so, I'm not saying anything like that, but "read the help" is the refuge of the flawed UI... a decent UI is such that, for the common use-cases at least, almost nobody needs to consult the help, because what you need to do is just obvious.
The topic was on the agenda for the design meeting. And while "Adapt table width" is clear enough given that we have a comprehensive help, there is room for improvements on the UI. So let's keep this one open for a UI redesign.
ODF has the ability to use relative column widths https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1420120_253892949 That is currently faulty in LibreOffice, see bug 109305. But it should be considered when improving the dialog.
(In reply to Regina Henschel from comment #4) > ODF has the ability to use relative column widths > https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/ > OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1420120_253892949 Interesting :-) Actually, it would be nice if one could specify column widths in one or several of: * Arbitrary relative values * Percentages and that is relevant irrespective of what gets saved in the ODF. Also, note that users may want to have relative widths for purposes of ease-of-editing, but not necessary for purposes of saving these values to the file. Or rather, _maybe_ users want to have this distinction, I'm not sure.
Created attachment 179458 [details] Mockup Discussion for this mockup at https://design.blog.documentfoundation.org/2022/04/11/improve-the-table-configuration-in-libreoffice-writer/