https://bugs.documentfoundation.org/show_bug.cgi?id=64028
--- Comment #30 from Stéphane Guillou (stragu) <[email protected]> --- Thanks Ady for the comment. (In reply to ady from comment #28) > IMNSHO, suggesting that "cut" in a spreadsheet tool could be defined in a > different way, or that the resulting action could be different than it has > always been, is not acceptable. I definitely understand that the default shouldn't be changed, and also agree that we shouldn't even allow to change the default with an Options dialog tick box. > All spreadsheet tools define the actions of > cut/copy/move/paste/reference/link in the same way, with the difference > being in method/UX (and in some cases, formula's syntax), but not in what > these actions actually do. We offer plenty of paste customisation, so I am not too surprised that users might expect some customisation options for what cutting does. One might think "I'm able to paste without formatting, so why should the formatting always be taken away by a cutting action?" > Considering that: > * there are (more-than-one) alternative ways to achieve the goal, and > that... > * when users gain more experience with spreadsheets then the need for this > kind of layout corrections tend to be less frequent... > ...IMHO the issue in question does not deserve more time from LO developers. > There are many other aspects of Calc that are much more relevant (for > users), and that have no current alternative available in Calc. The enhancement request is of "low" priority currently, and could be an easyHack. (In reply to Cor Nouws from comment #29) > There are situations where encouraging the reporter/user having better > understanding/explaining where to get that, is a much better way to handle*, > than trying to find a 'solution' which is somehow weird/against the natural > use. > This bug, with the simple available options to do what the initial request > appeared to be, and the extra additional/different issue in comment 18, IMO > fits into that category, where proper understanding is the best help > possible. Of course, but: - we have to be careful not be pedantic about "this is how things should be done", especially when users repeatedly hit their head against something (which is the case here) - the bug was closed in comment 19 as "works for me", which should be for "there was a bug but it has somehow vanished". I understand that was based on a misunderstanding, focusing on only the paste step, which wasn't the focus anymore. If not offering an extra UNO command is what the community, and in particular the Design team, prefers, I'm perfectly fine with that. But in that case, let's close as "won't fix" with a recommendation to use macro and/or develop as extension. Heiko, would you like to put this one on the UX/Design meeting agenda so others in the team can have a say? -- You are receiving this mail because: You are the assignee for the bug.
