Prevent DevonThink from editing certain or all file types.

I like that I can quickly highlight in documents, but in WebArchives, I don’t understand why I can destroy or alter content so easily by mistaken keystrokes.

There are certain file types I want to keep the content locked, but I want to keep the file unlocked (or at least not have to remember to manually set the lock for all files of that type).

Better yet, I’d like the option for “Double click opens document in external application”. Bonus points for letting me pick what file types get which action (PDFs need to open in Preview, images in my chosen editor, but I’m happy to let DevonThink continue to edit plain/rich text).

But of course, keep the preview pane for use in looking at files and icons.

It should be at least possible to undo the changes.

You’d be surprised how often I destroy a web archive without realizing it… Undo is not useful when you don’t know you’ve messed up a file and quit the program. You only find out the damage you’ve done when you reopen the app and eventually go back to look at the document you wanted.

How difficult would it be to have a setting that would prefer external editors for double-click?

We might add such a preference but you can already achieve this via a keyboard shortcut (Cmd-Shift-O), the toolbar or the (contextual) menu Open With > …

I’d still like to lock DevonThink out of editing certain file types all together, but thank you for taking the time to listen to me.

There are other cases that make the request for designation of external editor by filetype more complicated.

Example: The RTF suffix is used by a variety of applications. Nisus RTFs, though, lose information if edited by TextEdit. Still other applications that save as RTF have their own proprietary codes, and information would be lost if those files were opened and edited under Nisus.

Example: Hybrid PDF files are generated by Papyrus 12 and by Pagehand. Documents produced by these applications are displayed in DEVONthink as PDF+Text. But hybrid PDFs produced by one of these applications cannot be edited by the other. And if such a hybrid PDF is edited by another application such as Preview or Acrobat, the file is no longer recognized as editable by the application that had created it.

So the filetype suffix alone isn’t specific enough in some cases to make designation of an external editor for a filetype suitable for all the files with that suffix in one’s database. If I use Pagehand, for example, I must remember to use ‘Open With’ and choose that application to edit some of my documents that have the PDF suffix. But I would not wish to make Pagehand the Finder default to open PDFs, as most of my PDFs cannot be edited under Pagehand.

Dagnab it, the universe still isn’t a safe place.

Not perfect, but you can make a smart group to find Kind is Web Archive, select all those documents, open the Info panel, and lock them all at once.

Hi Korm,

could this solution be made scriptible? Could you give us a hint how to accomplish it (i would need it to protect my nisus writings).


What would the script look for that wouldn’t already be obvious by looking at the smart group? How do you know something is one of your Nisus writings - the name, a tag, something else?

Oh, sorry, you’re right i shall specify this. I thought about auto-locking all rtf-files. Alternatively it would be possible to me to name them [nisus] at the end (say “myfile [nisus].rtf”) before dragging them into

Because i would like to drag my nisus files to devonthink it seems not to be the best idea to do the locking manually.

I have many pdfs on my Mac created and edited with different programs. The Finder has no problem in choosing the right app for the specifc pdf I doulble-click. I have different rtfs on my Mac created and edited with different apps and the Finder has no problem choosing the right app for a given rtf.

The Finder applies a set of rules examining the various metadata in a file. There have been long discussions on this topic during the transition from Mac OS 9 to Mac OS X and although the new solution is not as user firendly as Mac OS 9’s way to handle this, OS X’s Finder is still able to make good choices in most of the cases.

Please correct me if I am mistaken, but as far as I understood, the Finder only resorts to the default app associated with a file extension in the specific case that there is no other metadata available besides the file extension.

Why does DevonThink treat all cases as this specific case and not do what the Finder does? Could DevonThink not do the same thing as the Finder? Look up all relevant metadata and apply the same rules as the Finder does in deciding which app to choose for a given document?

Doing as the Finder does would be OK. Doing better as the Finder would extraordinary. But not adapting to the Finder’s rules and abilities for a finderlike task?

I know there were changes to this in Snow Leopard but don’t recall specific details offhand; try Google: snow leopard default application. :slight_smile:

Snow Leopard ignores creator codes. Creator codes are set by the creating app and were used in earlier versions of OS X to designate what apps opened what “flavors” of RTF, PDF, and so forth.

Thank you korm, you are right. Apple abandoned creator codes in Snow Leopard without replacing them with something better.

The point I whish to make is that DevonThink could be more friendly to users who prefer to work with their external apps for rtf, png, jpeg, doc, txt, … . I would like to encourage the developers to consider helping those of us who whish to edit their files with external apps. Give us the choice - in an elegant and user friendly way - and let us get more out of DevonThink.

• John Gruber:
or: There is no replacement for creator codes in Snow Leopard

Snow Leopard Snubs Document Creator Codes

Finding Avie [some history]

• Chris Suter:
Creator Codes Are Not Replaced by Uniform Type Identifiers

• Matt Neuburg:
Snow Leopard Snubs Document Creator Codes

• Peter Hosey:
How not to use UTIs

• John Siracusa:
Metadata madness [including a suggestion how to solve the problem]

I wasn’t expecting you to be my Google proxy, omen, but thanks for that link summary. :slight_smile:

Most of those articles are familiar. I hadn’t tried to remember details since I wasn’t (and am still not) running SL, though I intend to install SL on a recently acquired MBP after it’s back from AppleCare repair with a new logic board (freely replaced, apparently a victim of the acknowledged NVIDA GPU problem).

Actually, that Creator Code debacle was one reason for postponing the SL update on my mini. Soon, finally, I’ll have first-hand experience with it and other SL issues.