I just did a mistake and moved a sheet and continued editing (overwriting) when I expected to copy the sheet and edit a copy (I overlooked the radio buttons on the top to select copy or move); so basically I lost quite some amount of work :-(. While I don't want to blame anybody else for my stupid mistake, I ask myself the question how often this happened before to anybody else, and how often it will happen in the future. In this case the application was not doing what I "intuitively" expected it to do. Of course this is often subjective, but good usability would optimally protect from that. I would suggest to make two separate context menu entries for move and copy. Alternatively, one could: - Make "copy" default; data will be duplicated and the obselete sheet can still be deleted, instead of resulting in an irreversible state - Move the "Copy"/"Move"-choice to a separate dialog that is shown before the main move/copy-dialog
I do not see the need for this, but I mark UX.
Copying sounds like the safer spot here, the OP gave a good example. Code pointer: sc/uiconfig/scalc/ui/movecopysheet.ui ("active" property of the radio button) Ideally, we change the button label from Ok to Move or Copy respectively depending on the selection. This needs a click handler, and text in the resource file. Medium difficulty therefore, the sole "active" property is beginner level.
If anyone is interested in solving this issue, I may offer myself as a mentor.
Laurent BP committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/170cdf5e335f8803b6d851a9d16020d277e73288 tdf#139464 Change label of OK button It will be available in 7.4.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.