calc forces the user to click on one of the column/line cells to move it after selection, when the natural thing would be to drag the column/line button used to select it
Sounds plausible at first sight. But I doubt that that will be modified because drag and drop Heading "B" behind "C" would let user expect that new order would be ACBD... @reporter: is there and Spreadsheet program doing it the way you request? Gnumeric does not.
That's how excel works for example and excel users have no such expectation as you describe: 1. they want to move column/lines 2. everywhere else in the office suite you can move items by selecting them, keeping the mouse button pressed, and dragging somewhere else 3. the column/line selection point is its heading So having to switch selection point to start dragging is completely unatural and non-obvious
See how confusing the current UI is there: http://www.oooforum.org/forum/viewtopic.phtml?t=56667
*** Bug 95964 has been marked as a duplicate of this bug. ***
*** Bug 120043 has been marked as a duplicate of this bug. ***
Not possible in OOo 3.3 either: OpenOffice.org 3.3.0 OOO330m20(Build:9567) It would conflict with the current behaviour of multi-row/column selection. It could instead require pressing Alt to make it consistent with the existing Alt + drag-and-drop of a selection.
The excel approach is highly efficient to the point that I switch over to Excel because it has this feature. Shift-drag allows moving with one drag, Ctrl-drag allows copying, and Shift-Ctrl-drag allows copying an extra set and shifting cells at the same time. This without moving from HOKAM (Hands On Keyboard And Mouse). Dragging anywhere on the border is currently unimplemented so leaving the button as is and implementing on the border would not affect existing users/methods. Anyone arguing against this feature should give it an honest try in Excel. Excel should be the reference implementation.
*** Bug 156695 has been marked as a duplicate of this bug. ***