Summary: | Moving rows (and columns too) in tables overwrites content | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | mikefreeman1972 |
Component: | Writer | Assignee: | László Németh <nemeth> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | cno, mark, michael.meeks, mikefreeman1972, nemeth, paddy, renato.wolp, sasha.libreoffice, s.bond1, stuart.sa |
Priority: | medium | ||
Version: | Inherited From OOo | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://issues.apache.org/ooo/show_bug.cgi?id=13645 https://bugs.documentfoundation.org/show_bug.cgi?id=56087 https://bugs.documentfoundation.org/show_bug.cgi?id=64902 |
||
Whiteboard: | target:6.5.0 target:6.4.0.2 | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 107707 | ||
Attachments: | Test case: Rose Dewar's resume template |
Description
mikefreeman1972
2011-03-22 15:38:40 UTC
Created attachment 53093 [details]
Test case: Rose Dewar's resume template
I would like to provide an example where this could be useful. Of the four templates included in LibreOffice for resumes in US English, the fourth one, by Rose Dewar, is closest to what I want. However, both my university's Web site and another site recommend placing "Education" before "Professional Experience." The problem is that Dewar's template is based on an invisible table, and since the headings are in the table, dragging and dropping around the Navigator is not an option. The ability to just drag and drop rows would make this quite easy.
I want to add that this is the default behavior on most word processors, including MS Word. [This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html reproduced in LibO master from 23 jan 2012 on Fedora 64 bit I can confirm that this is still an issue with the latest release candidate as of January 23, 2012. This problem still exists as of the latest 3.5.3 release (May 2, 2012). Is there any intention of fixing this bug? Just like when moving any other elements in a document, insert should always be the default case, not overwrite. Intention of fixing exist. But currently not enough resources. Sorry for such situation. Gosh; it'd be nice to fix of course - but I imagine, while un-expected, it is not such a debilitating bug that it can't be learned and worked around. Of course, I'd love a fix - if you want to get involved in hacking on it you're most welcome. http://cgit.freedesktop.org/libreoffice/core/tree/sw/source/ui/docvw/edtwin.cxx#n3922 Is prolly a good place to read around - the mouse down / up methods etc. HTH. Thanks for code point. It is very useful for fixing problems with table editing Also exists in 4.0.2.1rc. Thanks for additional testing. Sorry, but "Version" is where bug supposed appears. Not a current version of LO. If bug fixed, we just closing bug. Changing back to 3.5.3 The bug is still present in version 4.0.3.3 and prior. May I change the version number accordingly? I have also added bug #64902 because it is virtually the same as this one, but involves columns instead of rows. *** Bug 64902 has been marked as a duplicate of this bug. *** Hi guys & girls, It makes no sense to write every release that this has not been changed. As long as it is not marked as such, it is not changed. Set this to the oldest version available - it is like this since the early days of OOo. Note that this behaviour in Calc was only changed some few (3, 4?) years ago. Also I am tempted to set this to enhancement :) It would be best of course, if there was some popup asking if you wuld like to insert or overwrite. Cor: "It would be best of course, if there was some popup asking if you wuld like to insert or overwrite." I humbly disagree. When you drag with the cursor, it points to a specific location, which is standard (always) to mean an insert, not an overwrite. I know of no text editor that behaves differently. Cor: You're welcome to change this to "enhancement" or whatever you wish, as long as it gets this issue fixed faster. I've been waiting for this for many years (since the OOo 2.0 days), and was promised from the OOo people, since before everything blew up and LibreOffice fork was made, that it would definitely be done in the 3.x series. I do understand, though, that this fork is by a different group and any promises by one is not bound to the other. As for the popup recommendation, I would imagine that would be the worst way to do it (no offense). Would you want a popup every time you went to move a section of a paragraph or an image? Of course not. You just want it to be inserted into the spot you dragged it to. Anything else (including the current table behavior) is just non-intuitive design, causing unnecessary extra work for the user. As for making comments about the version it affects, I do this for two reasons: 1. Because I guess I misunderstood that "Version" means the first version it affected, not the most recent version it affects. That's sort of vague and should maybe be clarified. 2. To see if anyone is actually paying attention. Squeaky wheel sort of thing. Thank you for your comments, though. I do appreciate it! HI paddy & mike thanks for your both comments. Hmmm. well .. I only can say: yes that I agree that changing the behaviour is a good thing. (mind that of course I've basically no influence on that, apart from trying to help development a bit by providing properly handled bug reports and growing the project in general ;) ) Bump. Still aggrivated at this in 4.2.0.1 Any progress? For years this has been a productivity-reducer for me; I'll echo previous commenters that, for me, the current behavior is never helpful and always harmful. I'm using 4.1.4.2. Alas, the problem is still here. The cursor changes to a pointer that implies there will be an insert, not an overwrite, so it's always a bit of a shock even though I now expect it. It's an unfortunate bug relic for a mature application. We're at Libreoffice 4.3.3.2, and this frustrating annoyance is STILL there? I know you guys aren't the original Sun Microsystems people, but I was told by one of their developer way back at OOo 2.x that this bug was planned to be fixed in the 3.x cycle. Many, many, MANY years later, and many years beyond the beginning of the 3.x cycle, and we're still discussing the problem. Does anyone know if this is even being noticed by anyone on the dev team? Hi Mike,
> I know you guys aren't the original Sun Microsystems people
Right - they went bust because they didn't build an ecosystem of people that supported development: either by contributing code, or by funding others to do that. As you say, it is years later - and I'm wondering why you're not contributing to fix this yourself =) It is clear that you personally are not fixing it just as much as any member of the development team is not fixing it.
Please do get involved; propose a patch, dig into the code etc. The frequent riposte to this is "but I'm not 'a developer'" - guess what, that's how everyone starts out contributing =) every developer you see today, was once - not one; if you're willing to learn, I'm willing to help you.
All the best,
Michael.
Alas, the problem is still present in version 4.4 (alpha). @Micheal Meeks, I hear what you say. As a non-programmer, I've contributed to open-source software in other ways (e.g. user help and documentation). However, this is one area where I am completely unable to help — we users depend on the programmers for this. This bug already seems to have a high priority. Could it be raised to the developers for inclusion? It is an important "paper cut" from the user's point of view. I've just tested this behaviour in Apple's Pages and it's the same thing, moving a table row replaces the content and leaves the original one blank. Even in regular spreadsheets that happens, unless you drag the entire row of the spreadsheet, in which case you get the option to move that thing to in between two other rows. In light of that, I'd say that a design choice should come before technical efforts anyway. enough arguments to mark this as enhancement It's now 2015, and LibreOffice 5.0 still has this bug. I've been repeatedly asking for this for nearly 10 years, since OpenOffice 2.0, and nothing's changed. Back then, I was told by the Sun Microsystems devs that the problem would be fixed sometime in OpenOffice 3.x. Then the big upheaval happened, and that the bug went unfixed in either OpenOffice or this LibreOffice fork. Should I have any hope at this point of this ever getting fixed? @mike, It's free software: anyone is allowed to contribute or to hire/find others to do so. And as you see with all the improvements over the past 4 years, it works. So there is hope :) Cheers, Cor Changing priority back to 'medium' since the number of duplicates is lower than 5 I have reopened Bug 64902 for solving this problem by new menu options, like in MSO, as also suggested in https://bz.apache.org/ooo/show_bug.cgi?id=13645#c2 Proposed solution: https://gerrit.libreoffice.org/#/c/85375/ tdf#35570 Writer: drag and drop rows/columns without overwriting cells of the target table. Instead, paste rows above or columns before in the case of enhanced table selection (clicking in front of the copied rows or columns) or in the case of wholly selected tables. At moving (without pressing Ctrl during drag and drop), remove the originally selected rows or columns instead of emptying them. László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4ea1f7363d68296219f371076a93d3e480289368 tdf#35570 Writer: drag and drop rows/columns without overwriting It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. László Németh committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/20d91d5f45f3d1429dd64ad27469368f36f5fe5e tdf#35570 Writer: drag and drop rows/columns without overwriting It will be available in 6.4.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. |