The TBX to DEVONthink package is updated with a one-click installer. This version is for markdown notes which are copied to DEVONthink’s Global Inbox.
TBX to DEVONthink - Installer.tbx (149.2 KB)
4 Likes
Thanks, this is super cool!
When I click on the Installer file to take a look at it, it immediately triggers and deletes itself. I’d love to see what it does before it executes. Maybe you could wrap it with a boolean so that that execution can be manual.
Also, when I tried executing the installer, it seemed to work. When I expand the container, I see notes named Prototype, Stamps, and Templates. I wonder if Tinderbox might get confused with these notes being named with other critical elements that use these same names.
@satikusala
Hi. Thanks for trying it out.
As far as your second post, there should really be no naming conflict since these Containers are protected through the “TBX to DT” container.
The idea behind the one-click installer was that there really should not be a need to poke around. After install the user interface is the the two stamps being generated. Use them, create a Note, use the p_DEVONitem prototype, set the PublishToDEVONthink boolean and press the appropriate stamp and the note should be copied to the DEVONthink Global Inbox.
@satikusala
Sorry, forgot about your first remark.
Copy “Publish TBX to DEVONthink” to a new TBX document. Select Online view, expand the “Publish TBX to DEVONthink” (the triangle) and make a ⌘-A. In the Edict-inspector turn off the Edict boolean (lower left corner). It should now be safe to click the INSTALLER and view its content.
1 Like
Thanks, but in several instances, that may not be accurate. If someone calls one or more of these notes, e.g., “Tempaltes,” by name rather than by path, if this note is higher up in the $OutlineOrder than the primary Templates folder then it will get called and not the primary templates folder.
I have a few of other observations:
You might want to add the disabled edict comment in the readme.
If you note the image above, you have a prototype named “Stamps.” is this intentional?
If you don’t use dark mode, as in my case, the text in the “Create DEVONthink record” and “Update DEVONthink record” notes is formatted white, so it looks as if there is no code when actually there is. This is also the case for all your Actions notes, Apple Script notes, and your “Run note action” stamp.
This is very nice! Thanks!
@satikusala
The Stamp is not part of Prototypes, it is a (now) empty container that before installation contained the stamps.
As to the possible name conflict I’m afraid I don’t understand, can you exemplify?
What is your suggestion for the color scheme. I use the default Tinderbox scheme and yes, I use dark mode. Should I publish in Light mode?
I did not say it was part of the Prototypes, I said “it was a prototype.” You can tell by the green circle around its icon and that $IsPrototye==true. If the note is empty and of no purpose I suspect you’ll want to delete it.
Yes, if you have two folders named “Tempaltes” and one is higher up in the $OutlineOrder, then Tinderbox will use that one and not the “real” “Templates” folder farther down in the $OutlineOrder.
It is a good idea to try to not have duplicate names of notes, specifically for notes like Prototypes, Templates, Library, Stamp, etc. There is no harm in having duplicate names for other the majority of notes.
Here is an updated version (light mode) with revised naming and some cleanup.
TBX to DEVONthink - Light Mode .tbx (131.0 KB)
3 Likes
This looks great. One idea; you could create a configuration note to ask people where they’ want the prototype and templates stored, or, like Stamps, simply put the Prototype and Templates in the expected Protyptes and Templates folder.
@satikusala
Thanks for the comments. As you know from previous posts I feel strongly about the “visibility” of a utility. The reason the utility-stamps are loaded in the “public” Stamps location is that the stamps ARE the public user interface.
I believe Eastgate is working towards getting a general, preferred implementation of the installation, and I would prefer to wait with changes until those guidelines are coming. Hope this is OK with you.
3 Likes
A safe and sure way is to use absolute paths whenever referring to a note by name. Doing so will avoid any problems with ambiguity and add clarity of intent. It also eliminates completely a particular class of bugs. Yes, this technique comes at the cost of more to type, but a forthcoming new feature will eliminate or at reduce this (I.e., Copy Note Path). This also adds the benefit of not having to restrict the use of comply used words (e.g., templates and hints).
1 Like
Not to gainsay the last but if doing a lot purely in code, $ID can be safer than $Path. Why? some characters that are natural in text can mess with the path parser. No foul there, just enlightened self-interest. Conversely, the number of 10-digit numbers most of us can map in (human) memory to a path is probably in the range zero to one. So there is no ‘right’ answer.
1 Like
That also has the benefit of being insensitive to the changes in the path of a note. A useful feature would be the ability to hover over an ID in action code and have the actual path of the corresponding note appear. This would aid debugging.
Zero in my case — and getting worse by the day…
2 Likes
It’s hard to know what is an ID and what is just a number. But still, the hover idea is nice.
When possible, I do urge people to use paths rather than IDs. But sometimes IDs are what one needs.
But, how would Tinderbox know to which note $ID referred, thinking of use in loops, functions, etc. alternately, how would the app know that an apperently literal 10 digit number/string is an ID?.
Meanwhile hovering the cursor over the title of a note in the text pane shows the full path ($Path) in a tooltip, but likely you already know of that.