Bug 90883 - WRITER: Selecting multiple rows/columns doesnt change the behaviour of insert buttons
Summary: WRITER: Selecting multiple rows/columns doesnt change the behaviour of insert...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Windows (All)
: medium enhancement
Assignee: Philippe Jung
QA Contact:
URL:
Whiteboard: target:5.0.0
Keywords:
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2015-04-26 15:49 UTC by Yousuf Philips (jay)
Modified: 2016-10-10 21:47 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) 2015-04-26 15:49:22 UTC
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.
Comment 1 V Stuart Foote 2015-04-26 17:01:15 UTC
@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.
Comment 2 V Stuart Foote 2015-04-27 01:20:38 UTC

*** This bug has been marked as a duplicate of bug 90821 ***
Comment 3 Yousuf Philips (jay) 2015-04-27 08:31:37 UTC
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.
Comment 4 Philippe Jung 2015-05-15 14:19:50 UTC
Commit in approach
Comment 5 Philippe Jung 2015-05-15 14:34:35 UTC
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.
Comment 6 Yousuf Philips (jay) 2015-05-15 20:25:20 UTC
Thanks Philippe for taking this one on. Removing ux-advise.
Comment 7 Commit Notification 2015-05-17 12:40:52 UTC
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.
Comment 8 Philippe Jung 2015-05-17 12:41:51 UTC
Patch merged. Setting status to resolved fixed
Comment 9 Mike §chinagl 2015-05-21 15:36:43 UTC
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)