Yes, move the note in Tinderbox then delete – or move somewhere else – the note in the external location (Notes, Evernote, file system folder, DEVONthink).
Besides your clarification, will subfolders be able to update in future TB versions? I have a folder for each annotated article and book in DT. This means nearly a hundred folders since I started using this system. Having all of them inside an adornment in the top level of TB is not that practical.
As there’s a load to doing all this fetching/syncing it was my understanding these watched folders/groups were meant for watching a few key items rather than hundreds.
That’s a good point because what I was attempting to to do is to link and organize visually all the annotations I make whilst reading my sources.
This doesn’t ammount to as much as to convert TB in a general file manager. And I can see the use of having more complex connections among annotations available for a writing stage. But it might be more than the watched folder feature can handle, or I may have misunderstood some important points for setting up a good workflow.
On problem here is that the mechanism for watching folders is quite demanding and therefore fairly slow. It’s meant as an inbox, rather than for cloning dozens or hundreds of items from your repository,
Recall, too, that it is useful to watch a DEVONthink group (or Evernote notebook, Notes folder, etc.) if you anticipate that that source is going to change.
Is it likely that your hundreds of groups, and potentially multiple hundreds of annotation notes, are changing much or at all?
Instead of watching DEVONthink groups consider dragging those annotations to DEVONthink and then setting $AutoFetch=false for them. The annotations’ contents will not be updated. If the time comes when some annotations in DEVONthink are updated in that software then set AutoFetch=true for those notes, they will update in Tinderbox, and then you can set $AutoFetch=false and “de-couple” the Tinderbox notes from their DEVONthink source annotations.
This way you can get your annotations into Tinderbox for mapping, linking etc. – a very good use for Tinderbox, without being concerned about watching and the resources it might consume.
I also find it useful, in relation to this, to make Table of Contents documents in DEVONthink (see the DEVONthink manual) and dragging those into Tinderbox. The TOC document has a list of links to open in DEVONthink each of the documents listed in the TOC.
2 Likes
Thanks for the suggestions.
I wonder if it will work to set $AutoFetch=false to the top watched folder or to the imported annotations from DT.
As for the DT TOC option, I will compare it to iThoughtsX.
Watched annotations cannot be moved from the top folder. Otherwise, they will be imported again. In order to be able to organize annotations within containers, I’m thinking of making aliases. These will be left in the top level.
The orginal annotations could be moved elsewhere and modified.These riginal files that will appear in searches.
Does this approach make sense?
I think you might have that backwards. While it’s true that if you alias a watched note and move the original somewhere else, the sync continues to work – I suspect that’s because you’ve uncovered unintended results. I don’t know for sure, but I suspect the design intention is that containers for watched groups are supposed to hold originals and not aliases, and some future release of Tinderbox might break your solution.
But since the text of aliases is the same as their original, why not just move the alias and leave the original in the top level container? This works the same as your suggestion but might be more future-proof.
1 Like
Because … ? How does iThoughts enter the picture here?
In my own testing, I have found that the advice to limit the number of watched folders is well taken - especially if you want to set $Autofetch.
I tested with a DEVONThink group with several dozen files of various types (Word, Excel, email with and without attachments) and I observed a substantial slowdown in TB’s responsiveness.
As I said in a separate thread, we need to be a little cautious about the risk of trying to turn TB into a file repository rather than a note repository.
2 Likes
I think it makes more sense to further process the originals because, unlike aliases, they can contain children/descendants, they show as results in queries, and their links can be subjected to actions and exported, if I get it right. In this setup the only function required from aliases is to remain in the top folder in order to avoid the annotations being imported again from the watched DT folder. I wonder if these assumptions are correct.
As for how future-proof this setup would be, it definetely is a crucial issue before proceeding any further. I am a newcomer to TB and cannot tell. It would be helpful to know the opinion of somebody from Eastgate.
Your assumption is correct.
However – I’m curious why, after importing text from your DEVONthink notes, and then using those notes to add children, links, etc., to build a new structure, you need to retain the little thread linking you back to DEVONthink? What’s the use case? Others might want to learn from the vision.
It just happens that I am used to iThoughtsX and so far a newbie with TB. That app would be able to map a DT TOC, permiting to open links to DT annotations. However, it will surely become short for further processing, and I better don’t enter another app in the workflow. I’ll just stick to TB and keep learning how to use it.
Mark B is travelling at a conference right now. Doubtless he’ll clarify in due course (conference duties allowing!).
I see the logic of the suggestion but I suspect an auto-update targeting an alias likely will be problematic. To do what want it would make more sense to go the already available route of getting a note to auto-fetch from DEVONThink - or indeed those notes that need this approach. The watched folder is, I believe, a form of inbox. Bear in mind the process is between apps from different vendors and which may also have tight (and legacy issue) links to yet other apps. I’d avoid thinking of a watched group as a (two-way) sync: I’ve clarified the aTbRef note to this effect. As people now tend to think of sync in terms of cloud-like updated access, I think it worth clarifying that this isn’t that sort of thing.
I often OCR pdfs, highlight and annotate them with MarginNote, and export them to DT. Some of the highlighted text in annotations is below standard to perform searches.
Keeping the links in the annotations imported into TB allows for the correction of text in DT. Those modifications will be automatically transferred to TB. A better copy of the selected annotations will improve later searches both in TB and DT.
I’ll read this thread with more care when I return.
The purpose of Watch Containers is to permit ad hoc note-taking on mobile devices, directing the notes (generally few, brief, and transient) to the appropriate Tinderbox container. We’re not trying to replace the user interface of DEVONthink, or to be a repository; Tinderbox plays a different role.
I’m using the Watch feature to retrieve only new text files in a folder, so that at any stage I can check that contents in a DT and TB folder match.
After the first import, I use a Stamp to delete the $DEVONthinkGroup of the folder, keeping it in a custom field, and to populate the $URL field of each annotation. I rely on $AutoFetch to update individual files.
Later on I can place back the $DEVONthinkGroup, if I am in doubt that such DT and TB folder match. It works and it doesn’t seem to be taxing on TB, as far as I can tell.
Cool @jmm. Could you provide us with the code for the respective Stamp you successfully created?
Cheers!