[Libreoffice-bugs] [Bug 113603] New: Enhancement: unified table management in Writer

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=113603

            Bug ID: 113603
           Summary: Enhancement: unified table management in Writer
           Product: LibreOffice
           Version: 5.4.2.2 release
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: medium
         Component: Writer
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: christianw_lehmann at arcor.de

Created attachment 137468
  --> https://bugs.documentfoundation.org/attachment.cgi?id=137468&action=edit
It proposes a unified solution for table management remedying the above
shortcomings

Copy/cut and paste elements of a table:
There is a principled difference between
1) copying/cutting some substructure of a table, i.e. a set of columns or rows,
and
2) copying/cutting parts of the content of a table, i.e. the content of a set
of cells.
In case #1, the user wants to change the table structure. In case #2, he wants
to change the content of the cells.

Currently, LO Writer ignores this distinction. It follows a mixed and
inconsistent strategy:
1) On marking some substructure of a table and copying/cutting it, always the
substructure as such (including its content) is stored and reproduced at the
goal position.
2) Nevertheless, on cutting the marked material out, the substructure in
question is left empty, so the user is given the impression that only the cell
content has been cut out.
3) Once the entire substructure has been stored, it ought to be possible to
insert it, respecting the column and row structure of the table. In other
words, a stored row should be pasted as an additional member of the existent
table rows, and likewise for a stored column.

As it is now, if one does want to insert the stored substructure at the target
position, one first has to insert the corresponding set of empty columns/rows
at the target position. Then one either marks the entire empty substructure or
puts the cursor into its first cell and then does 'Paste'. This is cumbersome
enough. Moreover, if one fails to provide the empty space, moving instead the
cursor into the target position and doing 'Paste', the entire stored table
substructure is pasted in the cell where the cursor is (useless function, as it
destroys the table structure).

Shifting a (set of) table columns/rows to a different position in the table is
a frequent action which LO Writer does not support at all. As it is currently,
this is a multiple-step procedure:

a) Mark the entire column/row. (3 mouse clicks)
b) CTRL-X extracts the content. (1 key)
c) Delete the empty column/row. (2 mouse clicks)
d) Put the cursor in the desired position and do 'insert column/row'. (3 mouse
clicks)
e) CTRL-V pastes the stored content in the new column/row. (1 key)
Total: 8 mouse clicks, 4 keys hit.

For all such operations of Copy, Cut, Paste and Shift, I suggest a principled
solution in the file appended here (which, if implemented, would render LO
table management by magnitudes superior to the functionality of competing
products ...). It requires far less clicks and keys; for instance, shifting a
row is done by one click and one mouse dragging. It also contains an example
table for your convenience, to try out the reported (dys-)functionality of
Writer.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20171102/c2f04774/attachment.html>