https://bugs.documentfoundation.org/show_bug.cgi?id=170865
--- Comment #19 from ady <[email protected]> --- (In reply to Telesto from comment #16) > Case A > 1. Open Calc > 2. Insert a couple of sheets > 3. Select one (or more) sheets -> No warning dialog at all Empty sheets, so it does not count. > It appears the intention of genetic warning of possible breaking a reference > somewhere. Without the end-user knowing if a sheet truly being referenced > somewhere in a different sheet (and even which sheet). The author supposed > to know it, apparently. > > The end-result is quite some 'scaremongering' effect, with genetic message > (why do I get the dialog: Are you sure you want to delete the selected > sheet?" in some scenarios and not in others; Case A versus Case B) and often > being a spurious warning after all (for example case C) The reason is to provide a second opportunity. Simple case when there are several worksheets: 1. Right-click on the tab of one worksheet. 2. The intention is to click on "Rename Sheet..." – I am well aware that there are other ways to accomplish the same goal – but accidentally the user clicks on "Delete Sheet" instead. Without the confirmation dialog, the user could easily delete a worksheet, instead of renaming it. (In reply to Heiko Tietze from comment #17) > (In reply to ady from comment #15) > > "Deleting the sheet will destroy references"? So, you completely ignore > > comment 4. > You are welcome to join the meetings. Your proposal was rejected as too > long I merely provided a generic example of what I wanted to convey. Feel free and imaginative enough to find a concise way to express it with clarity. There is a difference between "you will certainly cause a problem" and "there is a chance that there might be a problem, but Calc does not have a clue whether there will actually be so". We have plenty of examples when no such distinction is made clear enough, especially for inexperienced users. If you are not even sure about the real consequences of deleting a worksheet, then leave it up to the user to decide (who eventually will be forced to learn), instead of adding such a generic warning that too many users would freak out, searching for some indeterminate (and potentially non-existing) reference (which is not the only thing that cannot be correctly undone when deleting a worksheet). > and Undo issues considered as... "manageable" I guess. No, UNDO is not "manageable". Either Calc is able to revert to the prior status after a specific action, or it can't. We, users, are simply "lucky" – thanks to developers, not a random event – that in many cases a mistake can be undone. Unfortunately, (too) many users expect this to be the case in every situation, and this is not actually true. You do not know how many different situations are there that cannot be correctly recovered by UNDO (and there are more than enough). In particular, when deleting a worksheet, you already know that there is at least one of those cases, but you also know (or should know) that there are more situations in which UNDO does not work as users tend to (over)expect. There is a reason for Excel not to even allow to undo the deletion of a worksheet. Calc might attempt to recover, with limitations. No additional confusing messages should be added. The confirmation dialog is not a tutorial regarding what exactly happens when deleting a worksheet. As soon as someone finds out that something else is not completely and 100% undone correctly, the request will come to add more details, warnings, info... Regarding the possibility to completely skip the confirmation dialog, it is certainly an expert configuration only. No common user should have to confront the situation. Completely-aware experienced users should take responsibility of deciding to skip one infrequent confirmation dialog. And if deleting a worksheet is so frequent that a user is tired of the confirmation dialog, then that user is most probably over-confident regarding this confirmation dialog in the first place. -- You are receiving this mail because: You are the assignee for the bug.
