Feature request: Stop page deletion by mistake

[jamesbond]

I’m not sure if this is a feature request for Rapidweaver or Stacks.

I am presently cleaning up the Partials in a project. If you have a Partial highlighted and hit CMD+Delete you don’t delete the partial, you delete the page that is active.

I realise this is 100% a user issue, but I can’t help feeling that there needs to be something put in place to stop this happening as although I accept it’s user error, it’s still too easy to do. The convention within most of the Mac OS is that the item that is highlighted gets deleted, but this isn’t the case in the scenario outlined above.

It’s made doubly bad by the fact that undo doesn’t work when you delete a page.

If possible, removing the ability to delete a page when something else is highlighted is one solution, but there may be others.

[isaiah (Isaiah Carew)]

There should be a warning sheet that is presented and says something to the effect of “Are you sure you want to delete this page?”

You should see a similar warning sheet any time you do anything that is not undoable. It’s a macOS behavior that’s been suggested since the very early days in 1984.

So my recommendation to @jamesbond is watch those warning sheets a bit more carefully when they pop down. I know I tend to click through these way way too fast myself. So I know how hard that can be – but it’s worth a try.

That said, there is an odd behavior here that I think we can point out to @dan and @tpbradley and @simon – i’ll need to get a tad tech-heavy and jargon specific, so you can stop reading here unless you’re a developer or interested in development:

this confusion stems from the fact that the File menu commands operate even when the source list (right sidebar) has lost the first responder status. when the user clicks a stack in the stacks library it highlights in bright blue (or the current system highlight color). if you click on a page in the source list the selection will change its highlight color to gray.

the key-bindings of the stacks library send actions to the first responder in the old-school AppKit way. if the first responder doesn’t respond to that action the menu commands are disabled and the key-bindings no longer work.

this works as expected with the arrow keys. e.g. select a stack in the stacks library and then arrow up down. you’ll select the next/prev stack as expected. then click in the source list and arrow up/down – you’ll move the selection in the source list as expected. that’s great – but the Cmd-Delete key command doesn’t work that way. it ALWAYS works. even when a stack has the bright blue selection focus and first responder status.

i know that there are exceptional cases when ignoring the first responder and making a menu command be app-specific can be an overall win. and i can see an argument that could be made that page-specific operations might fall into that category – since you are always on one page or another – there’s never ambiguity over which page you mean, so why not? right?

but in this case the problem is that cmd-delete might be expected to delete other selected objects. it’s a very generic sort of key binding – and does work that way in some apps. and we all know how easy it is to simply click that warning sheet that pops up without reading to make sure it’s deleting the thing i think it is. how many times have you clicked through one of those without reading yourself? my own answer: too many times to count.

my humble recommendation: leave the rest of the File menu commands as-is – but make delete require that the Source List actually have first responder status. yes, this could cause confusion, but unlike the confusion that exists today – it will never cause loss of data, which is substantially worse.

i don’t think this is a “bug” per se. it’s more of a – hey, maybe we can make RW a bit more friendly if we changed this a tiny bit.

but take it with a grain a salt – i think there’s plenty of room for debate and consideration of the platform as a whole when thinking about this.