Bug 104443 - Add 'Row' tab to Table Properties dialog
Summary: Add 'Row' tab to Table Properties dialog
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 128351 133091 135250 150136 (view as bug list)
Depends on:
Blocks: Writer-Enhancements Writer-Table-Properties-Dialog
  Show dependency treegraph
 
Reported: 2016-12-06 18:01 UTC by Mike Kaganski
Modified: 2022-07-27 07:45 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
(Mockup) New tab Rows in Dialogue table properties in Writer (45.34 KB, image/png)
2018-10-22 10:45 UTC, Roman Kuznetsov
Details
(Mockup Source) New Page tab in dialogue Table properties in Writer (16.28 KB, application/gzip)
2018-10-22 10:46 UTC, Roman Kuznetsov
Details
Mockup v.2 (46.85 KB, image/png)
2019-11-08 14:13 UTC, Roman Kuznetsov
Details
Screenshot MSO (12.56 KB, image/png)
2020-07-30 08:40 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2016-12-06 18:01:22 UTC
The "Allow row to break across pages and columns" checkbox is available in Table Format dialog (Text Flow tab). It is a per-row property, and works accordingly: if no cells are selected in current table, then it works for all rows; but if any cells are selected, then it shows/sets the property for those rows only. In case when the selection includes rows with different values of the property, the checkbox is set to "undefined" third state.

But that it works like that isn't evident on the tab. One can suppose that this is per-table property (I had supposed so for many ears until today, for one), despite the "row" is used in singular there.

The proposal is to also add the same checkbox to "Row height" dialog (available in menu Table->Size->Row Height...). The checkbox could fit there rather well, despite it's not directly a height-controlling property (still, it controls vertical layout of the row). Because the dialog is specifically row-oriented, the applicability of the property would be evident. And because the property is also accessible from Table Format dialog, so the Row Height dialog wouldn't need a rename (because the added option is just a convenience option).

Added checkbox should be disabled when whole table's property to break is disabled (just like it works on Text Flow tab of Table Format).

The duplication of functionality is not a problem here: there are a number of places where we duplicate functionality. E.g.: "Go to page" vs Navigator; Column Width vs Columns tab of Table Format; font settings on toolbar vs Character format etc.

An alternative could be to add a tab to Table Format dialog named Rows, and place row-specific (height and break) controls there.
Comment 1 Heiko Tietze 2016-12-11 09:41:15 UTC Comment hidden (no-value)
Comment 2 Heiko Tietze 2016-12-19 16:17:13 UTC
Doubt that adding a checkbox to one dialog solves unclear behavior somewhere else. Not saying such a checkbox makes no sense, though.

Ideally we get a preview of how the settings look like.
Comment 3 Cor Nouws 2016-12-20 08:16:34 UTC
I think the idea is well thought about and reasonable.
Only simpler that comes to my mind, is changing wording from 
"Allow row to break across.." to
"Allow (selected) row(s) to break across.."
Ahum..
Comment 4 Yousuf Philips (jay) (retired) 2017-05-02 19:24:21 UTC
(In reply to Mike Kaganski from comment #0)
> The "Allow row to break across pages and columns" checkbox is available in
> Table Format dialog (Text Flow tab). It is a per-row property, and works
> accordingly: if no cells are selected in current table, then it works for
> all rows; but if any cells are selected, then it shows/sets the property for
> those rows only. In case when the selection includes rows with different
> values of the property, the checkbox is set to "undefined" third state.

So this checkbox should be changed to only work at the table level and be labelled 'Allow all rows to break across pages and columns'.

> But that it works like that isn't evident on the tab. One can suppose that
> this is per-table property (I had supposed so for many ears until today, for
> one), despite the "row" is used in singular there.

Yes this confused me as well.

> The proposal is to also add the same checkbox to "Row height" dialog
> (available in menu Table->Size->Row Height...). The checkbox could fit there
> rather well, despite it's not directly a height-controlling property (still,
> it controls vertical layout of the row). Because the dialog is specifically
> row-oriented, the applicability of the property would be evident. And
> because the property is also accessible from Table Format dialog, so the Row
> Height dialog wouldn't need a rename (because the added option is just a
> convenience option).

No i doubt anyone would find it if it was put in that dialog.

> An alternative could be to add a tab to Table Format dialog named Rows, and
> place row-specific (height and break) controls there.

Yes this is one of the features that i've been meaning to suggest be added as it baffled me why we have a column tab but no row tab. Also i had seen a row tab in MS Word. - http://ic.ims.hr/office/word2003/slike/37/table-properties-in-word-2003.png
Comment 5 Roman Kuznetsov 2018-10-22 10:45:08 UTC
Created attachment 145898 [details]
(Mockup) New tab Rows in Dialogue table properties in Writer
Comment 6 Roman Kuznetsov 2018-10-22 10:46:19 UTC
Created attachment 145899 [details]
(Mockup Source) New Page tab in dialogue Table properties in Writer
Comment 7 Cor Nouws 2018-10-22 21:12:46 UTC
(In reply to Roman Kuznetsov from comment #5)
> Created attachment 145898 [details]
> (Mockup) New tab Rows in Dialogue table properties in Writer

@kompilanen: looks nice - how to indicate when whole table's property to break is disabled, so that per row the boxes for breaking are disabled too ?
Comment 8 Roman Kuznetsov 2019-11-08 14:11:23 UTC
*** Bug 128351 has been marked as a duplicate of this bug. ***
Comment 9 Roman Kuznetsov 2019-11-08 14:13:44 UTC
Created attachment 155637 [details]
Mockup v.2
Comment 10 Stephen 2019-11-11 02:59:30 UTC
Comment on attachment 155637 [details]
Mockup v.2

Dear Roman, 
I support your effort. I suspect the "previous row" and "next row" approach will suffice (no need to list all rows together), since very large tables with each row listed might be difficult to capture (placing the list in a scrolling window would be interesting). Looking at the last feature on the page, "Repeat the first # rows as heading" is interesting innovation. I prefer to turn off breaking across pages, and I think this is important specification, but I am not sure that providing this this option for each row separately has value.  thank you.
Comment 11 Heiko Tietze 2019-11-11 10:27:03 UTC
I wonder if we should/can have Fit to size and Allow break for every single row.
The Apply to all checkbox needs description, eg. all but Row 1 get disabled and input on this spinner is taken into the other. We could alternatively have radio buttons All, Individually and same controls for All.
Comment 12 Heiko Tietze 2020-07-30 08:28:12 UTC
*** Bug 133091 has been marked as a duplicate of this bug. ***
Comment 13 Heiko Tietze 2020-07-30 08:40:29 UTC
Created attachment 163756 [details]
Screenshot MSO

Microsoft's solution
Comment 14 Heiko Tietze 2020-07-31 12:37:04 UTC
*** Bug 135250 has been marked as a duplicate of this bug. ***
Comment 15 Telesto 2020-12-20 15:46:29 UTC
(In reply to Heiko Tietze from comment #13)
> Created attachment 163756 [details]
> Screenshot MSO
> 
> Microsoft's solution

FWIW, kind of liking the MSO solution.. listing all rows in dialog feels strange?
At least I would select the rows for which I want to set height, before going to Table Properties -> Row. And if nothing specific is selected, it would apply for the full table
Comment 17 Heiko Tietze 2022-07-26 12:36:54 UTC
*** Bug 150136 has been marked as a duplicate of this bug. ***
Comment 18 Jax 2022-07-26 13:36:57 UTC
Agreed; 150136 is more or less a duplicate, as long as we consider the menu option language for getting to set options, consider changing specific, selected rows and change the online help files which are out of date.

Thanks for spotting the duplicate.  I missed it as I was listing an error that seemed different at first (lack of findable menu option).

I like the simple MS implementation (mocked up in earlier comment) and Heiko's busier but comprehensive mock up at https://design.blog.documentfoundation.org/2022/04/11/improve-the-table-configuration-in-libreoffice-writer/  which promotes fewer tabs but a busier dialog box.  Perhaps the question would be if users typically and commonly altered both Columns and Rows simultaneously.  I guess that I actually do one then the other and tweak one set of dimensions at a time.  There; I've decided: One tab for Rows, One for Columns.  That's my suggestion.

Current menu option could be quickly renamed to [Table] > [Cell Size] for clarity.  [Table] > [Size] sounds like dimensions for the entire table area.

Current Help Files are misleading and wrong.
Comment 19 Heiko Tietze 2022-07-27 07:45:25 UTC
(In reply to Jax from comment #18)
> Perhaps the question would be if users typically and commonly
> altered both Columns and Rows simultaneously.  I guess that I actually do
> one then the other and tweak one set of dimensions at a time.  There; I've
> decided: One tab for Rows, One for Columns.  That's my suggestion.

The current split between Table offering options regarding the total size and Columns with details per item is not the best solution. If the tab is too complex now we could hide options behind expanders or in extra pop-up dialogs.