Accidental editing in the Outliner

In the Outliner, when you double click a document, the doc gets selected and the field under the mouse opens for editing. That works just as I’d expect.

But if a doc is already selected, it only takes a single click to open the clicked field for editing. And that goes at least somewhat against expectations.

Although technically there’s no reason to click on an already selected doc unless you want to edit the clicked field, I’ve found myself doing just that, causing the clicked field to unexpectedly open and go live, resulting on a few occasions in accidentally losing content, mostly in the synopsis field, as a result of an unfortunate key press or two that clear or otherwise change the content before the field closes – after which the original content is beyond undoing.

The documentation (12.2) says “You can edit by double-clicking into the text field you wish to edit.”

But as it works, it only takes a single click to edit a text field. Here are three scenarios.

  1. When double clicking on an UNSELECTED doc, the first click selects it, and the second click is what opens the field for editing.

  2. When double clicking on an ALREADY SELECTED doc, the first click activates the text field, and the second click doesn’t seem to do anything – it seems to just get lost somewhere between the first click and the full opening of the field.

Neither of those two scenarios seem like accurate descriptions, but then there’s this third scenario.

  1. When SINGLE clicking on an ALREADY SELECTED doc, the clicked field opens for editing. And that’s why I believe 1 and 2 are accurate descriptions (at least experientially.)

Most of the time, the difference between 1 and 2 isn’t noticeable and has no consequence. But because of 3 (which is a slow-mo version of what normally happens in a couple hundred milliseconds); and because clicking on a doc, even when it’s already selected, is such an easy and common thing to do (e.g., to insure proper focus); and because such clicking is perfectly safe under most circumstances (think of editing in the corkboard); single clicking in the outliner produces counterintuitive results that are inherently risky: it can unintentionally expose content to accidental editing.

Interestingly, there is a precedent to this “single click to edit” in Explorer: if you single click on an already selected file (in the right-side pane), it opens for renaming. But there it’s just a file name, which can’t easily be damaged (illegal names are rejected) and can in any case be undone.

In Scrivener, it’s the combination of the unintentional/accidental field opening, with the lack of undo once those fields close, that sets up occasional data loss. It would be easy to not realize it.

At this point I’ve learned to be careful, but that’s just another way of saying that there’s something about the outliner I’ve learned to not entirely trust: Lead me not into user error. :mrgreen:

I can’t quite follow everything I described above, 8 years (and 1 Scrivener version, and 1 forum platform) ago. But, using the outliner just now, for the first time since S3, I knew I’d seen this before. The parts quoted below could have been written by me today—fortunately, I didn’t have to! :wink:

I realize that in some ways, this behavior could be considered normal. In this context, for me at least, it still stands as undesirable…

Hi, Mad girl etc. :wink:

I played with this, and I think the real problem is that there isn’t an Undo, after you might have changed a title.

We’re sort of safe, aren’t we, as at least the insertion point precedes the current title, so that you’d have to do deliberate things in order to actually lose that – a mistake would only add?

The funny thing is, that Undo you mention in Windows Explorer for filename changes…

  • I hadn’t known that was there, no indications or menu items, so thanks :slight_smile:
  • and it’s funky in its own way, besides invisibility: there is no undo as soon as you move off the item you changed.

I thought of more, in this Outliner locale, but discretion is often the better part of valor, I think we both know, not so? :slight_smile:

You take care, wherever you are,
Clive

The click/double-click behavior you mention is standard behavior for a Windows list report control, such as Explorer’s file list in Details mode. I suspect the Qt control used by the developers is just a wrapper around the Windows control, so you get its default behavior.