| Summary: | EDITING: moving columns/rows with <alt+drag&drop> overwrites instead of ousting | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Martin Peter <metapeter> |
| Component: | Spreadsheet | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | breakphreak, bugs, cpohle, jmadero.dev, LibreOffice, metapeter |
| Version: | 3.5.7.2 release | ||
| Hardware: | Other | ||
| OS: | Mac OS X (All) | ||
| Whiteboard: | BSA | ||
| i915 platform: | i915 features: | ||
| Attachments: |
Screenshot for bug 58440, showing the page from LibreOffice Help in LibO 3.6.4.3 on Mac OS X
Screenshots comparing overwrite - ousting mode Screenshot of LO Help on shortcuts for moving cells |
||
I can't see any special Mac hint for this on <http://help.libreoffice.org/Calc/Moving_Cells_by_Drag-and-Drop>, so I believe reporter simply uses the wrong keys? @Martin Peter This is not a good place for "I don't remember" problems, please use <http://help.libreoffice.org/Calc/Moving_Cells_by_Drag-and-Drop>. Please check whether Help hints work for you! Hallo Rainer, i justed tried this on my windows machine, and it works over there (LO 3.5.6.2). On the windows box just pressing alt while D&D makes exactly what it should - it _moves_ the selected column from one place to another. On my mac machine pressing alt while D&D copies the column instead of moving it. As for the "i don't remember" problem, where are one step further. This problem obviously wasn't unique to me and apparently it had been solved for win systems: http://ask.libreoffice.org/en/question/1143/how-to-move-columnsrows-in-lo35/ Do you need more information? Thanks for any help to come. Martin Hm, I also have a (different?) problem with LibO 3.4 and 3.5.4 on Ubunu on VirtualBox, because alt+mouseclick is for windowsmanager (as mentioned on ask.libreoffice). I wonder whether this also is a current Linux Problem. Of course this problem is completely different to reporter's, the sum might be thet this <alt+drag&drop> is a "WIN only" solution and works nowhere else? Roman, can you confirm this problem? (In reply to comment #3) > Roman, can you confirm this problem? Well, I have tried the steps given in comment #0 with LibreOffice 3.6.4.3 (Build ID: 2ef5aff) on Mac OS X 10.6.8, and I see a problem, but a different one: no matter what combination of keys I press (Cmd, Alt, Ctrl, Shift, and all their combinations), the column does neither move nor gets copied at all; the only thing that changes sometimes is the number of selected columns. But maybe I am just too stupid, or was not patient enough ... (In reply to comment #4) A little more detailed description 1. fill the first three fielda (A1,B1,C1) of row 1 with random data (for example "a","b","c") 2. select colum C by clicking the column header 3. <Alt> (or whatever required for Mac) 4. Click into C2, keep mouse button pushed 5. Start moving mouse pointer to the left Mouse pointer changes to "Not here" in C2 6. When you have trespassed border C->B Mouse pointer changes to "Move", Border between coluns B-A becomes bold 7. When you have reach middle of Be release mouse button > Contents of columns B,C have interchanged. That's the way how it works with WIN, and this does not work under Ubuntu (May be because of other reasons). If a last attempt failed please please make this one new for Markus, he already fixed other bugs ("Bug 46230 - EDITING: impossible to perform a drag & drop of entire row/column"). Some Hints: In German help you find instructions under "Zellen per Ziehen&Ablegen verschieben", please check after we have finished here whether Help has to be amended. Mouse pointer View see "Ziehen&Ablegen innerhalb der LibreOffice-Dokumente" (In reply to comment #4) > (In reply to comment #3) > > Roman, can you confirm this problem? > > Well, I have tried the steps given in comment #0 with LibreOffice 3.6.4.3 > (Build ID: 2ef5aff) on Mac OS X 10.6.8, and I see a problem, but a different > one: no matter what combination of keys I press (Cmd, Alt, Ctrl, Shift, and > all their combinations), the column does neither move nor gets copied at > all; the only thing that changes sometimes is the number of selected columns. > > But maybe I am just too stupid, or was not patient enough ... Hi. I guess you are trying do drag the column by clicking on the header. The dragging operation should be started with a click into the column-selection. The selection itself is achieved by clicking the column-header once, after selecting, you drag the selected fields. The key to hold for (expected) moving of columns should by ALT as i found out by now. In Win it works just fine. Regards @ Rainer Bielefeld: thank you very much for your detailed instructions! Testing with LibreOffice 3.6.4.3 on Mac OS X 10.6.8 (Intel), I get the following results. (I) Pressing no keys at all --------------------------- When I follow Rainer’s instructions from comment #5, but do NOT press any key, i.e. leave out step 2, and just drag column C between column A and B, I would expect the following result: | A | B | C | D | ... ------------------------------------------------- 1 |a |c |b | | ... But I get this result: | A | B | C | D | ... ------------------------------------------------- 1 |a |c | | | ... I.e., the contents of column C overwrite the contents of column b, instead of ousting them. But this is not a bug, because the LibreOffice help says (in section “moving cells by drag and drop”): No key: Cells are moved and overwrite the cells in the target area. Source cells are emptied. Strange, but so it reads, and therefore this is what is expected. (II) Pressing Alt key --------------------- Following Rainer’s instructions from comment #5, including keeping the <Alt> key pressed during the whole drag-and-drop action, I get the following contents in Columns A to D after step 7: | A | B | C | D | ... ------------------------------------------------- 1 |a |c |b |c | ... So column C has been *copied* (not moved) between columns A and B. On Mac OS, pressing <Alt> is often used for copying data instead of moving them. So this could be intended behaviour. The LibreOffice help says (in section “moving cells by drag and drop”): 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. I confess that IMHO this description is somewhat irritating. There should not be any “except if...” clauses in descriptions of expected behaviour. But if I understand the description corectly, the current behaviour is correct: the “except if you move within the same rows on the same sheet” applies, and so the source cells are not emptied. Do you want me to test more key combinations? Until now, I only see irritating descriptions, but not a bug. But maybe I am just too stupid for this kind of tests. (I prefer real bugs that crash LibreOffice ;-) (In reply to comment #7) > But maybe I am just too stupid for this kind of tests. > (I prefer real bugs that crash LibreOffice ;-) Sorry for the loose wording. What I wanted to say is: IMHO the expected behaviour, as described by the LibreOffice help in the section “moving cells by drag and drop”, is so irritating and counter-counterintuitive, at least when we speak about dragging and dropping whole columns or rows, that I feel frustrated by judging what is a bug or not, because the expected behaviour feels like a bug to me ... So, just tell me if you want me to test more key combinations, and I will describe my results, but if the results are a bug or not a bug should be judged by somebody else. (I would just regard the complete expected behaviour as a bug.) (In reply to comment #8) > (In reply to comment #7) > > But maybe I am just too stupid for this kind of tests. > > (I prefer real bugs that crash LibreOffice ;-) > > Sorry for the loose wording. What I wanted to say is: IMHO the expected > behaviour, as described by the LibreOffice help in the section “moving cells > by drag and drop”, is so irritating and counter-counterintuitive, at least > when we speak about dragging and dropping whole columns or rows, that I feel > frustrated by judging what is a bug or not, because the expected behaviour > feels like a bug to me ... > > So, just tell me if you want me to test more key combinations, and I will > describe my results, but if the results are a bug or not a bug should be > judged by somebody else. (I would just regard the complete expected > behaviour as a bug.) Thanks for your efforts. Is it intended, that LibrOffice on Mac lacks the moving-columns-capability, which exists in the Windows version of Libre Office? Regards Martin (In reply to comment #9) > Is it intended, that LibrOffice on Mac lacks the moving-columns-capability, > which exists in the Windows version of Libre Office? This is what the LibreOffice help says: > No key > Cells are moved and overwrite the cells in the target area. > Source cells are emptied. > > Command key > Cells are copied and overwrite the cells in the target area. > Source cells stay as they are. > > Command+Shift keys > Links to the source cells are inserted and overwrite the cells > in the target area. Source cells stay as they are. > > 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. > > 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. > > 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. Can you find the alluded “moving-columns-capability” in this list? If not, it is really missing ... (In reply to comment #10) Currently it looks as if Mac LibO is lacking this function. Additional there might be a Help problem, but I d not know whether Mac has it's own Help texts different from WIN Help? From where is the Help citation? In WIKIHELP <https://help.libreoffice.org/Calc/Moving_Cells_by_Drag-and-Drop> I only find the non-Mac wording, and in Manual 3.4 "Using Spreadsheets in LibreOffice" I can't find anything concerning this drag and drop. Created attachment 72059 [details] Screenshot for bug 58440, showing the page from LibreOffice Help in LibO 3.6.4.3 on Mac OS X (In reply to comment #11) > From where is the Help citation? From the “LibreOffice Help”, available inside of the LibreOffice application via the “Help” menu; the page is entitled “Moving Cells by Drag-and-Drop”, and available when I select “LibreOffice Calc” from the pop-up menu at the top left of the Help menu, switch to the “Index” tab, and search the index for “moving; cells by drag and drop”. Please cf. the attached screenshot. It shows the US English version of the help. (In reply to comment #11) > Additional there might be a Help problem, but I d not know whether Mac has > it's own Help texts different from WIN Help? I would guess it has, because (cf. my screenshot) the help text talks about the Command key, which is specific to Mac OS X. But please compare the text visible on my screenshot to the version available in LibreOffice for Windows. If there are any substantial differences, it is clear that there are platform-specific versions of the LibreOffice help. Created attachment 72990 [details] Screenshots comparing overwrite - ousting mode (In reply to comment #13) Due to comment and screenshot Help seems ok, that's a plausible equivalent of the function I expect and see in WIN The Mac test seems to be: 1. fill the first three fielda (A1,B1,C1) of row 1 with random data (for example "a","b","c") 2. select colum C by clicking the column header 3. Click into C2, keep mouse button pushed 4. Start moving mouse pointer to the left Mouse pointer changes to "Not here" in C2 6. When you have trespassed border C->B Mouse pointer changes to "Move", Border around column B between become bold 7. When you reached middle of B2 press <Alt> (or whatever required for Mac) Black border at right of column B should disappear, what announces that column D will shift right old column b contents. 8. Release mouse button > Contents of columns B,C have interchanged. The question is whether you can find any Key (combination) what will let disappear right border in step 6 *** Bug 61116 has been marked as a duplicate of this bug. *** Created attachment 75119 [details]
Screenshot of LO Help on shortcuts for moving cells
(In reply to comment #14) > [...] > 7. When you reached middle of B2 press <Alt> (or whatever required for Mac) > Black border at right of column B should disappear, what announces that > column D will shift right old column b contents. > 8. Release mouse button > Contents of columns B,C have interchanged. > > The question is whether you can find any Key (combination) what will let > disappear right border in step 6 The key combination, that lets te right border disappear on mac are "alt" or "alt + ctrl". While the result of the drag&drop operation with both key/key-combinations is identical, the behaviou while performing the operation is slightly different. 1) D&D Column C and pressing "alt": * A green "+" icon appears next to the pointer, indicating a copy operation * The right border dissappears * Result: C ousted B to the right, but a copy has been created instead of moving now it looks like this: | A | B | C | D | ---------------------------- 1 | a | c | b | c | 2) D&D Column C and pressing "alt + ctrl": * The right border dissappears (no icon appears) * Result: see above, exactly as 1) when pressing "alt" So 1) and 2) have the same result, while the appearing "+"icon whilst performing the drag and drop operation is the only difference. Although it isn't documented I suppose the combination "alt + ctrl" to be ment for "moving" columns because it lacks the "+" icon but it's still removing the right border as one would expect for the moving operation. LIBRE OFFICE HELP I attached a screenshot of the mac manual with the drag and drop shortcuts (attachment 75119 [details]). It is somewhat confusing and even erroneous. The "Command" key is beeing confused with the "Control" key. For example: using the Command key alone has no effect at all, whilst performing drag & drop operations on cells, rows or columns - the help claims the opposite. So, the help seems to be messed up seriously at this point. So, is there any key combination that allows the rows/columns to be moved by dragging? *** Bug 61116 has been marked as a duplicate of this bug. *** (In reply to comment #18) > So, is there any key combination that allows the rows/columns to be moved by > dragging? No, not to my knowledge. That's why i filed this issue. I consider this a OSX specific application bug in combination with an erroneous documentation. I've also checked with 4.0 version - same issue. And, also checked with the latest version of Open Office - same issue. This is a very common (missing) functionality to me, wonder how other people are coping with the issue. (In reply to comment #20) > (In reply to comment #18) > > So, is there any key combination that allows the rows/columns to be moved by > > dragging? > > No, not to my knowledge. That's why i filed this issue. I consider this a > OSX specific application bug in combination with an erroneous documentation. I totally agree: this is an OSX SPECIFIC BUG since ever. I had the same issue with OpenOffice but only on OSX platform. I never had problems on Windows versions. On OSX I never had the chance to move&insert cells with drag&drop. As Martin well explained on #17: two different GUI behavior -> same result. I was waiting for the new release but this limitation persists. Marking as NEW due to last comment Any idea when this recurring bug under OSX will be adressed ? Latest version to this day under OSX (4.0.4.2) has the bug. Too bad ! If you're going to up the importance please tell us why - we tend to not like just priorities jumping up. Use this flowchart: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg to help guide you in determining the appropriate priority. According to the flowchart, marking it as HIGH doesn't seem outrageous to me : this bug is a productivity killer and surprinsingly it's been around for quite a long time. In the end, it could lead users to head for some other piece of software. I doubt it should be too difficult to fix, but I might be wrong on this one, as I'm not a developer. Feel free to lower it back, and thank you to the community for the hard work. It's a great piece of software despite of all. Best regards. This should be HIGH priority! This problem is still not resolved in 4.1.4.2 release. Instead of "moving cells" by alt-drag&drop (as described in help file) the software does a copy&insert. Nothing gets overwritten, but data gets duplicated. If you want to rearrange a bunch of rows (lets say each row represents a country and you want to sort these rows by drag&drop) you and up with a lot of duplicated rows and often end up deleting the wrong ones. It really cost me a lot of time compared to LO Windows an all Excel versions! PLEASE FIX! Alex Please don't update version - version is oldest version the problem is confirmed on. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Problem description: I used to move columns and rows several versions ago (~1year) without problems. I don't recall the exact keyboard shortcut while dragging a column to move it (it was ctrl+shift or cmd+shift or alt+ctrl or alt+cmd) Steps to reproduce: 1. fill the first three fielda (A1,B1,C1) of row 1 with random data 2. select colum B by clicking the column header 3a. grab the selection and drag it to the right of column C 3b. try the following shortcut-combinations while dragging the column (ctrl+shift or cmd+shift or alt+ctrl or alt+cmd) Current behavior: A: Column will get overwritten with a _copy_ of the dragged column OR B: A _copy_ of the dragged column will be created, while the original column remains in place Expected behavior: column B _moves_ to C, and former C is now in column B Thank you, bye Operating System: Mac OS X