Tinderbox Forum

Bookends import

The Bookends import using OPT-CMD-drag and drop is great. However, is there a way to configure Tinderbox so that it renames the notes that are created so they have names such as “PublicationYear”+“ArticleTitle” or some other instead of just “ArticleTitle”? I wondered whether it is possible to create a rule/action to automatically modify newly created notes.

I am a total beginner, trying to evaluate Tinberbox to see whether I can get it to do what I would like to do with it.

You can’t configure within the drag process but it’s trivially easy to use an action to set the note’s title ($Name) to the year and article title. Try this code in a stamp:

$Name = $PublicationYear + ": " + $ArticleTitle;

How you effect that code is a matter of choice. I’d use an edict (or totally manual stamp) rather than a rule or agent. Why? You really only need to do this once, so re-applying the name constantly is a waste of effort (albeit the CPU’s, not yours).

Also, if the $ArticleTitle contains any of the following characters, you might want to remove or replace them:

) ( ; "

Why? Because currently those interfere with Tinderbox’s query-parsing, e.g. in agents. Don’t forget you have the ‘original’ title string safely in $ArticleTitle. Best substiutions are [ ] square brackets for parentheses, colon for semi-colon and straight single quote for straight double quote.

Does that help?

Very helpful indeed, not least because the links in your email took me to the Tinderbox reference file that I had failed to find. One of the things I like least about Tinderbox is the documentation. As someone said in a posting that I just discovered, the information the newcomer needs seems to be scattered all over the place. Thank you very much.

FWIW, aTbRef is my own personal effort (thus the different domain). Errors & omissions welcomed. note that Tinderbox is a Toolbox for notes. Using the toolbox analogy aTbRef describes the functionality of a hammer tool rather than describes the endless list of tasks during which it may be used. Writing how-to scoped articles for each person’s use (people’s usage is actually remarkably varied) would take an army of authors, so it’s a task to leave to others.

To get the best from the docs and the (helpful) community here, try to describe the process you are trying to do rather than the outcome. There are two good reasons for that. Firstly, pictures in one’s mind’s eye—however vivid—translate poorly to prose. Secondly, there is rarely a single right method to an end-point in Tinderbox (it’s a toolbox!) so understanding what you are doing and context helps us help you by suggesting methods best aligned with your work-style. Instead of asking “how do I get cake?”, ask “what is needed to make a cake?”. In this arena, the latter is much easier to assist with. :slight_smile:

Have you seen this?

Thank you for the link, which looks wonderfully helpful. I had not realised who created which support documents.

I take the point about not giving people a formula, because there are many ways to use the toolbox, but for complete beginners, there is a need to be told one way simply to find out how to do basic operations and get started. You need to learn the basic concepts and how to create different objects before you can even start to think about alternative ways of doing different things. For example, following your last reply, I managed to create a Stamp, but I had to consult a couple of different places to find out how. Similarly, Prototypes are crucial, and I have found one (or was it two) ways to create them, but I need to do further inquires to work out how to modify them. I am sure there is a logic behind the way documentation is provided, but it can be baffling to a newcomer.

Thank you for your help. I appreciate it.

Standard response. I too thought the same and made no progress, until I saw the problem was how I looked at the problem. We’re used to the above because “Computer says: No!” is the common user experience. We’re schooled that there is a sweet spot to rewarding use, we just have to submit to the designers intent.

For deeper tools a little consideration of the task at hand repays massively. I don’t mean that in the sense that “App A does this, but at App B we do it this way.” Far from it, the joy of a thinking tool is tools with which to think.

Let’s step back. Consider your opening problem. What sort of an article/title where you expecting to find and that might help unpick the disconnect.

If you feel this is push-back I can only say I’m writing this as I break out from a significant re-factoring of aTbRef to answer the issue of how to set attributes using the UI: 2 person-days effort and counting. so, it’s not that you’re being asked to join a different cult (which seems the normative software experience, IME). :slight_smile:

I should add I’m glad to hear you are making progress. If info on stamps ins in several places, I think—hypertextually—that’s right; because we want to reduce redundancy. Ironically, documenting a constantly evolving open-ended thought tool is one of the more difficult documentation tasks. There is no one right way, so no one right article to capture the constant. Plus the affordances grow/change constantly, even if only at any one time for very small sub-sets of users.

But, don’t give up! :slight_smile: