In calc, if you select multiple rows or columns of a sheet and insert rows/columns, it inserts an equal amount of rows/columns as to what has been selected. But this behaviour isnt available in writer's insert commands (.uno:InsertRows, .uno:InsertColumns) in the table toolbar.
@Jay, hate to state the obvious, but Calc's cells/columns/rows have no data structure in common with Table's cells/columns/rows. Yes it is worth looking at for consistency of UI. I'm not sure of all details of the exposed attributes for Writer Tables, but the enhancement may simply not be possible. In general, there is no reason to expect .uno commands affecting Calc sheets to function the same when the .uno command is affecting Tables in Writer (or other modules that implement tables). For Writer Tables the insertRow, insertColumn UNO commands insert rows and columns one at a time, it does not replicate the multiple row, or multiple column selected "counts" as implemented for the actions in Calc. Likewise, selection of rows/columns in Calc is not the same as its counterpart in Writer Tables. These selections also happens to use the same UNO commands--but also have different actions appropriate to the Object type. For example, notice that with a Table, you can select multiple rows/columns with <Shift> selects, but you cannot then deselect a row or a column (with <Ctrl> select). There are different structures and exposed attributes for UNO actions to affect. These misconceptions of a shared data structure and function lead to issues like bug 37223.
*** This bug has been marked as a duplicate of bug 90821 ***
Reopening as bug 90821 doesnt cover what this enhancement intends to fix. (In reply to V Stuart Foote from comment #1) > @Jay, hate to state the obvious, but Calc's cells/columns/rows have no data > structure in common with Table's cells/columns/rows. I'm quite aware that they dont. ;D > Yes it is worth looking at for consistency of UI. I'm not sure of all > details of the exposed attributes for Writer Tables, but the enhancement may > simply not be possible. I believe it will be possible. We can detect when an entire row is selected, as you can see it in the statusbar, so using the same information, we should be able to change the behaviour of the uno commands to insert accordingly. > In general, there is no reason to expect .uno commands affecting Calc sheets > to function the same when the .uno command is affecting Tables in Writer (or > other modules that implement tables). Not saying that it should, but i'm suggesting that unifying the behaviour means that its easier for users to have a consistent experience between the apps. > Likewise, selection of rows/columns in Calc is not the same as its > counterpart in Writer Tables. These selections also happens to use the same > UNO commands--but also have different actions appropriate to the Object type. I'm aware of this, which is why i have asked that alternative insert uno commands be created for writer which have the similar insertion direction behavior (bug 90882). Another problem is that these same named uno commands have the single icons to them when they have different behaviours, which also causes more problems.
Commit in approach
https://gerrit.libreoffice.org/15741 The behaviour is now coherent with the button extended text: When several rows / columns are selected, an equivalent number of rows / columns are inserted.
Thanks Philippe for taking this one on. Removing ux-advise.
Philippe Jung committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d49242026ed9e342871b437998a40a253e4f26c8 tdf#90883 WRITER: Insert button with multiple rows/columns selected It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Patch merged. Setting status to resolved fixed
This bug fix is mentioned in the release notes of the coming LibreOffice 5.0 (see release notes https://wiki.documentfoundation.org/ReleaseNotes/5.0). Therefore it would be wonderful if this feature really worked well, otherwise it should not be mentioned in the release notes. In the notes it reads: Inserting rows or columns is affected by a user's pre-selection, similar to Calc. tdf#90883 (Philippe Jung)