Bug 119936 - LibreOffice Calc macOS keyboard shortcuts for moving cells not behaving as expected in help
Summary: LibreOffice Calc macOS keyboard shortcuts for moving cells not behaving as ex...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Documentation (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All macOS (All)
: medium normal
Assignee: Not Assigned
URL: https://help.libreoffice.org/7.6/en-U...
Whiteboard:
Keywords:
: 147009 (view as bug list)
Depends on:
Blocks: Shortcuts-Mac Help-Changes-Features
  Show dependency treegraph
 
Reported: 2018-09-17 16:05 UTC by steve
Modified: 2023-12-31 12:02 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
alt + drag on macOS 10.13.6 + LO 6.0.6.2 (1.12 MB, video/mp4)
2018-09-20 07:34 UTC, steve
Details

Note You need to log in before you can comment on or make changes to this bug.
Description steve 2018-09-17 16:05:07 UTC
Description:
Wikipage about Calc > Moving Cells by Drag-and-Drop here:
https://help.libreoffice.org/Calc/Moving_Cells_by_Drag-and-Drop

has key strokes which do not apply to macOS. macOS users are left in the dark as to how the feature is to be used resulting in rather high frustration.

Steps to Reproduce:
1. Visit https://help.libreoffice.org/Calc/Moving_Cells_by_Drag-and-Drop
2. Try to use described key presses

Actual Results:
Either nothing happens, or something other than described in the wiki.

Expected Results:
Proper behavior as described in the wiki.


Reproducible: Always


User Profile Reset: No



Additional Info:
Adding a column to the wiki table with macOS key presses would help. And then again, this is a much bigger issues, since I guess it applies to all wiki pages giving keyboard shortcuts. Not sure how to best solve this large scale.
Comment 1 steve 2018-09-17 16:09:58 UTC
Sidenote: I have rather strong feelings about the default mode being overwrite. I would expect non-descructive insert mode to be the default and simple to use thing. Remaining data is always removed easily, but once data is lost and maybe lost is not instantly discovered, irredeemable damage may be done.
Comment 2 Alex Thurgood 2018-09-17 16:14:47 UTC
Confirming with LO6112

Excel's help and the spreadsheet functionality is much easier both to use and understand in this regard.

For example, to move a column of data wherever I want, even in between existing columns :

1) Select the data column header
2) Move the mouse over the frame of selected data, the icon changes to a hand.
3) Press Shift key and drag data column to insert wherever I like. Notice the visual hints also given to the user (similar to LO's tooltip) as to where the column is going to be inserted.

LO in contrast requires a certain degree of  manual dexterity to achieve the same thing that would be impossible, or nigh in impossible, for physically impaired users.
Comment 3 Alex Thurgood 2018-09-17 16:37:29 UTC
In LO367, at leat there is a visual hint when dragging column/row data to a new spot, where a bold line appears to show in between which column/row the data is going to land
Comment 4 Olivier Hallot 2018-09-19 11:31:31 UTC
The page referred is now

https://help.libreoffice.org/6.2/en-US/text/scalc/guide/move_dragdrop.html?System=MAC&DbPAR=CALC#bm_id3155686

Note that the contents changes when call is from a macOS computer (?System=MAC).

Please check if the contents are correct now and, if not, please provide the equivalent contents changes in the page above, including current valid keyboard shortcuts for macOS in a simple document or comment here and I'll make it go to the help page above.
Comment 5 steve 2018-09-20 07:34:27 UTC
Created attachment 145050 [details]
alt + drag on macOS 10.13.6 + LO 6.0.6.2
Comment 6 steve 2018-09-20 07:35:26 UTC
Thanks a lot for clarifying Olivier. I should start using LibreOffice help instead of a search engine to find solutions I guess.

Tried https://help.libreoffice.org/6.2/en-US/text/scalc/guide/move_dragdrop.html?System=MAC&DbPAR=CALC#bm_id3155686

but still do not understand the bevahior.

Issue 1: Why not allow users to drag columns + rows by clicking on the Letter (column) or number (row)?

Issue 2: The KB documement says
"Option+Command keys

Cells are copied and shift the cells in the target area to the right or to the bottom. Source cells stay as they are."

I tired that but the row I drag to keeps being overwritten and the source fields are not moved but copied. They stay in their original place. This seems to be wrong and not behaving as described.

Can someone double check? Screencast attached (alt ⌘ drag operation.mp4)
Comment 7 steve 2018-09-20 07:36:50 UTC
Correction: not overwritten. Point being: content is not moved but copied. Really unsure if this is a bug or expected behavior. But I am so far unable to really "move" cells as.
Comment 8 Alex Thurgood 2018-09-20 08:22:03 UTC
(In reply to steve -_- from comment #7)
> Correction: not overwritten. Point being: content is not moved but copied.
> Really unsure if this is a bug or expected behavior. But I am so far unable
> to really "move" cells as.

Yes, I can confirm that the data is only copied, not moved, when using the Option key.
Comment 9 eisa01 2020-02-17 21:51:29 UTC
So this now has the macOS keyboard keys after the move to online help

However, I'm not sure the behavior is as described

Also a separate issue that should be filed: How things look when you drag and drop is also just a "dot", in LO 3.3 you at least also had a grid

No key:
Cells are moved and overwrite the cells in the target area. Source cells are emptied.
Actual: Yes (no key on windows)

Command key:
Cells are copied and overwrite the cells in the target area. Source cells stay as they are.
Actual: Can't hold cmd+click at the same time, only seem to be selecting the cell. If holding cmd while dropping, same result as no key (ctrl key on windows)

Command+Shift keys
Links to the source cells are inserted and overwrite the cells in the target area. Source cells stay as they are.
Actual: Same as above
Workaround: ctrl key achieves the described result! (ctrl+shift on windows)

Option key
Cells are moved and shift the cells in the target area to the right or to the bottom. Source cells are emptied, except if you move within the same rows on the same sheet.

If you move within the same rows on the same sheet, the cells in the target area shift to the right, and then the whole row shifts to fill the source area.
Actual: Yes, but source cells are never emptied (not able to get this on Windows, possibly due to VMware)

Option+Command keys
Cells are copied and shift the cells in the target area to the right or to the bottom. Source cells stay as they are.
Actual: Yes, but that is same behavior as without shift

Option+Command+Shift keys
Links to the source cells are inserted and shift the cells in the target area to the right or to the bottom. Source cells stay as they are.
Actual: No, same as only option
Comment 10 steve 2020-02-19 22:01:17 UTC
Updating title. If a new bug is preferred, feel free to create one.

was: Documentation: LibreOffice Calc Wiki page should have column for macOS keyboard usage
updated:
Comment 11 eisa01 2020-05-09 23:38:35 UTC
There's also issues with moving rows that should be seen in conjunction with each other
Comment 12 eisa01 2022-02-06 15:30:21 UTC
*** Bug 147009 has been marked as a duplicate of this bug. ***
Comment 13 eisa01 2023-12-29 18:01:25 UTC
So I take it the help file was changed to reflect the macOS shortcuts (command + option)

Now the issue is that not all of them work as described

As there are bugs in the actual implementation (bug 58440), I'm closing this as updating only the help wouldn't make it all work as Windows/Linux
Comment 14 steve 2023-12-31 11:52:16 UTC
Not sure if this issue should be closed.
Comment 15 steve 2023-12-31 12:02:56 UTC
Sorry, post was sent to early while adding URL.

Help page URLs have changes and the relevant page now is https://help.libreoffice.org/7.6/en-US/text/scalc/guide/move_dragdrop.html?&DbPAR=SHARED&System=MAC and I have added it to the URL field of this issue.

Probably fair to continue this in #58440 though.