Locked Document Alarm

DEVONthink Feedback
1

A beep or other alarm would be an improvement when attempting to edit a locked document, as would be preventing that document’s name from being changed.

Most notable is going to a locked document, positioning the cursor in the content, starting to type as if to edit, hitting a space, and then having the document suddenly scroll.

Also changing the locked document’s name is possible and is not locked. Plus, the modified date does not update if changed.

I lock certain older documents to prevent changes to them, but sometimes I do accidentally attempt to edit them. An alarm at the first attempt in doing that would be helpful and names should not be able to be changed in a locked document.

2

It would be abnormally and counterintuitively undesirable (to me) if changing a document’s name also updated its modification time. I can’t think of any app I use that behaves that way.

3

OK, understand your point but the real issue is being able to change the name in a locked document. That should not be permitted.

4

Locking a document in DEVONthink does not prevent changes to the metadata of the document, including adding tags, Spotlight Comments text, or Name change.

A common use of locking is to prevent inadvertent changes to content, especially in cases such that information would be lost, e.g., by editing a Nisus Writer RTF file using the built-in DEVONthink text editor.

The Lock action in DEVONthink does not lock the document against an external editor. For example, an RTF document that has been locked can still be opened and modified using “Open With” and choosing the parent application, e.g., Nisus Writer.

I use a couple of applications that create “hybrid” PDF documents, editable lunder their parent application, but viewed in DEVONthink (and other applications as wwll) as PDF. Were I to edit such a hybrid PDF within DEVONthink or Preview, it would not longer be editable under the parent applicaation. I “lock” such files. It’s a good idea to append to the name a reminder to myself of its proper parent application, wheich I can still do by a Name change even after locking it. The purpose of locking, of course, is to prevent inadvertent editing under DEVONthink, Preview, Acrobat, etc.

By design, the Lock action in DEVONthink is not identical to the Lock action in the Finder, which would entirely prevent modifying or renaming a file.

A number of users employ document naming systems that provide information to them, and they are free to modify the name of a document stored in a DEVONthink database, whether or not the document is locked. For example, I might create a rich text note that includes the name of a reference that it annotates, and append to the name whenever I wish, “locked” or not, other information, e.g., a textual “cue” string that could be used in a Lookup search to designate a scrolling position of a document in the result list view of the referenced document – a little trick that I often find useful.

Or I might add a YYYYMMDD “date” string as a prefix to a set of document names in order to make that set sortable by “date” in a Name sort. This will work whether or not any of the documents are “locked”. I might use that trick for receipts, publication dates, historical records or a variety of other purposes.

In sum, many DEVONthink users would resist an extension of the “lock” metaphor in DEVONthink to preclude Name change of a “locked” document.

5

@Bill_DeVille: Thanks for your time with the examples, comments, and some helpful tips. I totally agree with your points and in fact, have done some you describe. The part of my suggestion about not allowing name changes was a hasty one.

But my real point was a suggestion to add a beep or other alarm if you attempt to edit the contents of a locked document from within DTPO. Nothing happens to the contents, but it is easy to seemingly start typing and suddenly have the document jump without warning after hitting a space.

Obvious disallowed operations in the content like a type style change or a Cut do now result in a beep. Other operations like typing characters and font changes do not.

Why not an alarm anytime the cursor is positioned in the locked document? That should cover all circumstances and still not interfere with something that is allowed like a Copy.

6

I see what you mean, especially if one selects a block of text and tries to do something with it, other than copy it to the clipboard.

But I use as a visible cue the fact that a cursor insertion point will not be displayed in a locked text document.

7

At least for me visual cues can be hard to spot in DT; it’s an aspect of the “focus limbo” issue I’ve previously written about.

8

Never noticed that. For me the vertical insertion line is there just not blinking.

Instead of a simple insertion I typically select, double or triple click on something in the locked document. Then start typing expecting to revise and replace the selection. Those actions appear the same as in a regular (unlocked) document.

9

OK, but the actions to select text are legitimate, as you might want to copy text to the clipboard. Do you want the computer to bong at you or worse, put up an error message (and worst of all, a modal message, perhaps offering the option to unlock the document) in that case?

A user whose intention is to select and copy text in a locked document might find a warning that the document is locked to be distracting and irritating.

A user whose intention is to modify a locked document will see that the effect of typing new text is nil. The little “Lock” symbol is visible in the navigation bar above the text pane.

So how should the UI be modified to accommodate different user intentions concerning a locked document? If there’s an audible or visible cue when an action is taken, what should trigger it and when?

10

Refining my previous suggestion: Why not an alarm anytime the cursor is positioned in the locked document and keys (alphanumeric) are pressed? Same as what happens now with invalid operations like a style change and Cut producing a beep while valid operations like a Copy do not.

It sounds like simply expanding the criterion for when a beep occurs.

Plus eliminate the annoyance of the unexpected scrolling when typing a space in a locked document.

11

And let’s not forget how Emacs behaves when typing in read-only buffers. :slight_smile:

12

I don’t think the majority of DTPO users care about Emacs. I do think the majority care about limiting the inconsistencies between actions in DTPO versus “standard” Mac actions that they experience in other applications.

Some differences may be necessary, as in how to handle locked documents in DTPO which Bill clarified previously. But most differences should not exist, as I mistakenly had suggested previously to update a file’s modification date with a name change.

13

My intention (implied by the smiley) was simply to lighten the discussion a bit.

Dtech has made changes that improved intra-app consistency (some which I’ve suggested) and will hopefully make more if arguments in their favor are convincing enough.