I am trying to get notes in a document to behave, by default, in a particular way (have a particular set of Attribute Values).
One simple way would be to have a prototype that is the default proto for new notes.
Is there a way to specify this? I know that for a container’s immediate children, one can do this via $OnAdd, but is there a document-wide default?
I also know that one may extend beyond the immediate children by bequething those children the same OnAdd action: if the prototype itself specified an OnAdd action, the children will have it, and thus one could propagate this to all descendants. I want to avoid that since it won’t work for top-level notes and also the OnAdd gets “used up” and if there is additional OnAdd work needed for some notes, I will have to be careful about continuing the inheritance of the default proto there; this is a solution that is fickle and finicky.
Furthermore, I want this to be the default proto, and if I drag a note into some container, I want to keep the proto of that note if it already has one; $OnAdd will overwrite it without extra logic.
The coding philosophy I am trying to follow in my document is to have something that is not easy to accidentally break. Manual Inheritance setup can go awry in so many ways, and I am looking for a clean way.
Alternately, is there a way to set attribute default value document-wide? This will address what I am trying to do with some properties set for all notes. I believe this can be done, but I am unsure if this is accessible via AppleScript. Applescript seems to allow me to set the attribute for the document, but not the default attribute value. Could this somehow be exposed?
What I am trying to do
Some words are in order to explain the many queries and requests I have been making on this forum. The way I see it, I am trying to “tame Tinderbox”. TB is a complex beast with many bells-and-whistles. I am trying to create a hygienic TB doc that makes it easy to add some idiosyncratic features using external tools, such as specifying prototype-specific (and thus context-dependent) action suggestions using Alfred, which a user may pick and choose from.
Another feature is to enable programmatic control to adding or updating various kinds of content; one practical use case for this is to keep the prototypes in many files in sync, by showing the user what prototypes can be imported and, if chosen, importing/overwriting these.
I hope to describe (and share) my work later this month.
Although a note is essentially the atomic element of a document, it is essentially a collection of attribute values. Thus, one way of looking at your request is to ensure all desired system attribute non-defaults are set before any notes are added plus any user attributes you require.
This is actually a well known model, colloquially referred to in the community as a ‘starter file’. In the simplest terms you do the above and add any other custom features (templates, composites, prototypes, link types, cusom colours, etc.) and Save the document to the ‘favourites’ folder within the app’s support folders. Indeed, you can have multiple files there. Any file in the folder is accessible in the app from the File menu’s ‘Open Favorites…’ sub-menu. Opening one of these files creates a new, unsaved copy of the source file, i.e. a new file with all your customisations.
It in’t possible, within the app, to force one of your starter files to be the ‘new file’ template but I guess you could make a feature request for that.
All system attributes’ defaults, except for those which are read-only (normally calculated values), can be set via the Document Inspector’s system sub-tab. A few (covered in aTbRef) can’t be set there as they are set in Document Settings (Cmd+8), though the Inspector will also indicate this fact.
If you haven’t already, read up on Tinderbox inheritance of attribute values.
Another useful wrinkle is the hasLocalValue() which is specifically there for ferreting out inheritance errors, such as altering a value locally when you meant to change it in the prototype.
One thing you can’t do, IIRC, is to make a system or user attribute read-only. I guess this could be done by altering the XML. But, if you’re thinking of trying that I would definitely work with a copy of your document and probably ask support first—their might be a good reason for not doing so.