Tinderbox Forum

Struggling with Tinderbox and a suggestion

I think you’d be best off using a Set-type attribute. Sets are list that automatically de-dupe, i.e. each note can only hold one entry for that value. IOW, someone can be an 'physicist and ‘astronomer’ but neither of those more than once. In a List-type, the term ‘physicist’ could occur twice. Thus, in non-techie terms a Set is a de-duping List although both are ‘lists’, i.e. attribute that allow more than one discrete value per note. By contrast, a String attribute allows one value.

So if you set an attribute with the value ‘physicist’, depending on the data type the result is:

  • String: “physicist”
  • Set: “physicist”
  • List: “physicist”

Now set the value to ‘astronomer’ and the result is

  • String: “astronomer”
  • Set: “physicist;astronomer”
  • List: “physicist;astronomer”

The ‘;’ in the set and List is how this is displayed in Key attributes - the semi-colon is the value delimiter. Now is we set the value ‘physicist’ again we get:

  • String: “physicist”
  • Set: “physicist;astronomer”
  • List: “physicist;astronomer;physicist”

Note how the Set de-dupes the result.

To follow onto @PaulWalters’s excellent suggestions, here is a little more about the way that set attributes work, and how they might apply in your case – including through the magic of the Attribute Browser view.

Suppose you create a file where, among other things, you’re listing various prominent figures by their names. You then create a new set-type attribute called (for instance) Roles, where you will enter as many or as few identities as you’d like for each person:

Then as you add each new person to the list, you can add as many or few Roles as you’d like. For instance, Leonardo might have three and Newton four:

Within the grammar of the program, values in set-style attributes are separated by semicolons, as in “Painter; Polymath.” (Idiosyncratic spelling for “Mathematician” – sorry, was doing this in a rush.)

In the Outline view, shown above, I’ve added a column (via the View/Use Columns menu choice), so that I see each person’s roles next to his name. But if I use the Attribute Browser, I can see the people grouped instead by roles:

This very simple example, which took me less than three minutes to put together door-to-door, gives an idea of the open-ended configurability of things. You can have attributes for just about anything you want; you can display them in different colors and arrangements and sorting schemes; etc. But, crucially, you can start with something as simple as this and then build up.

Update Weirdly, probably because I was typing this entry at the same time, I didn’t see @mwra’s careful explanation of set-type attributes, immediately above, until just now. His explanation is obviously useful and right on the nature of sets in TB.


One strategy that has helped me to learn the mechanics of Tinderbox is to use it for things that have a clear objective. Like the other day, I was comparing some software packages. I dragged links to their home pages into Tinderbox to make notes for them. I know that price is a concern, so I made an attribute for that, and could easily compare them with attribute browser. I read the home pages and took notes on the things that interested me most, and any concerns I had… which helped me get a better understanding of the features that I wanted or needed. I made attributes to represent those features, and again was able to compare them in attribute browser. Agents helped me find the software packages that had all the features that I wanted, or ones that I hadn’t gotten answers on yet. Demoing the software helped me fill in the details.

Decision-making is just one use case where I find Tinderbox helpful… but it illustrates the concept of having a clear objective in mind. There’s an end-state to my Tinderbox usage in that scenario.

The example also demonstrates the incremental formalization concept discussed in The Tinderbox Way. When first getting started, I wrote my thoughts into the note $Text. After doing that a few times, I noticed patterns emerging – specifically, features that I wanted in the software. When I noticed those patterns, I added a bit more structure – the attributes. And finally agents are another form of structure that helped me visualize the information better.

Crucially, I was able to archive that document and not think about it again. If the software I purchased ends up a disappointment, I can always revisit my original notes. But I don’t have to spend any more time thinking about “how do I use this software effectively?” I had an objective, I accomplished it, and now it’s time to move on to the next thing.

That’s been my experience with it… I hope it helps others.


Good example, @pat.

Tinderbox sits in my dock. Clicking it and starting a new document is as reflexive as picking up a blank sheet of paper and a pen. I would guess 90% of my documents have the intent of what @pat describes above. The other 10% are longer-term hefty analyses or writing projects.

For small, purposeful projects,I have several templates stored in ~/Library/Application Support/Tinderbox/favorites – and I use these as starting points by picking one from Tinderbox > File > Open Favorites. For example, I have a starting-point template for task planning, another one for journaling. In these I’ve defined some standard attributes, agents, and export templates that I know I’ll need every time I do task planning or journaling.

That’s interesting… because it’s not that way for me. For whatever reason, I have this idea in my head that a Tinderbox file is “heavy”. I realize it takes almost no space on disk of course, so that’s not it. I’m not really sure where the idea comes from.

I think it has to do with the fact that I almost always save Tinderbox files in some folder, rather than in a DEVONthink database. And the more I use DEVONthink (7 years and counting), the more I hate saving things to a folder. I LOVE my DEVONthink databases… in particular how I can get a link to a record that always works, no matter where I move the record (as long as it stays in DEVONthink).

The idea of having a hundred Tinderbox files in a folder gives me anxiety… but I have no problem doing the same in DEVONthink. So, I know what I need to do :slight_smile:

Tinderbox as fast-and-easy as paper is a powerful metaphor…

1 Like

Oh, well. I have a lot of Tinderbox starting-point docs defined in DEVONthink’s ~/Library/Application Support/DEVONthink Pro Office/templates.noindex folder also – and I can get to starting points using Data > New from Template… in DEVONthink.

I store or index most Tinderbox documents in DEVONthink. So if I start one outside of DEVONthink it is always saved in a folder that is indexed in DEVONthink. And in DEVONthink it’s super easy to suck indexed documents into the database.

Got’cha coming and going :smile:


Nice yeah I think I’ve avoided TB documents in DT because it throws off the “see also” big time… and they can show up in search results a lot more than I’d like (there are a lot of words in that XML markup!). Though I just did a little test, and it doesn’t seem to be happening anymore… I wonder if DEVONtech changed how they index XML for “see also” purposes.

Anyway, there’s no harm in making a Tinderbox-specific database where I can archive those files… and I can put them in my main database to see what happens to “see also” / search, and move them out just as easily.

Thanks for the New from Template tip :slight_smile:

1 Like

I’ve struggled with Tinderbox for years. I’ve quit a few times but over the long run I’ve kept at it. I do think it’s possible to create an introductory course that could set new users on more fulfilling path (and sell more licenses) but who is going to pay for it? The economics of Tinderbox, as far as I can tell, don’t support hiring a contractor, and a volunteer effort would require an enormous commitment of time and energy.

So I’ve bowed to that reality and I carry on year by year, taking three steps forward for every two steps back.

You know what would really help, though? If someone was kind enough to put together a very basic beginner’s guide to Tinderbox coding’s vocabulary, logic, symbols, and syntax, all located in one easy to find place. I believe that would save newbies a lot of pain and bring a lot more people into the Tinderbox community.

1 Like

How about Getting Started With Tinderbox?

The Help menu includes two good tutorials “Getting Started with Tinderbox” and “Actions and Dashboards”, both in PDF form. Once open in Preview you can save them to disk to read in slow time without the app open if needs be.

Also, and though I’m not suggesting it’s written as a guide, rather a reference, but do look aTbRef does cover the above. A few starter places in it:

Edit: sorry for unintended duplication - I see @eastgate posted whilst i was replying.

Much as I have beat the drum for the value of learning this software in a case-by-case way, as opposed to the normal systematic approach most of us would instinctively take, it’s worth noting that the links above do provide quite a lot of top-down system view (especially Concepts) and extensive reference material. “Getting Started” also has a lot of illustrations with both conceptual-and-practical info.

In my own case, now that I feel I understand the general “feel” of the program, my usual approach is: figure out what I’d like to do in a certain case, try to do it, and then look in the reference charts (“List of action codes” / “Date format”) if I need to tweak the exact syntax. Or ask here.


Thank you everybody.

1 Like

I also recommend Stephen Zeoli’s video series on Tinderbox


Totally agree with this point. aTbRef is great for people who have a sufficient understanding of TB. It is an invaluable reference once one has a basic grip of the app. But, it is not the right place to start to learn TB. The “how” parts are missing.

Don’t try to learn TB from aTBRef!
aTBRef is a reference; not a textbook.

What helped me to get started with TB was primarily the “Getting started” guide. Then, some of the videos and Mark’s tutorials (he had somewhere…I don’t know where they are now: ); and Mark’s (and, recently Paul’s) replies in the forum. I have asked all my trivial questions. I always get wonderful replies.

So, for the beginners, please don’t hesitate to ask even the seemingly “trivial” questions.

1 Like

Some of them are here


Though last published before Tinderbox 6, the concepts are still fresh and useful, IMO.

Depends on how one learns, I suppose – most of what I know about Tinderbox came from aTbRef.

1 Like

Indeed! Also:

And some more I’m sure I’m forgetting at the moment. Update: and many are collected here: http://eastgate.com/Tinderbox/Screencasts.html


Just speaking personally, this is almost exactly what I was looking for:

Thanks for the advice, especially the nudge to go a little deeper into TBRef

1 Like

Yes, I have tried this one. But, he had some others in a cloud space: Clarify-it…

I find some of them now:


1 Like

Ah, the main listing for these is at http://www.acrobatfaq.com/tbdemos/clarify.html. I think the most useful are probably those on Prototypes/Inheritance and on explaining the Inspector. I’ve indicated v5 vs v6 ones - a few I’ve re-done since v6 changed the UI. There aren’t any significant UI changes since v7 so most of the v6 demos should make sense still. I don’t re-do everything as a matter of course as they actually take quite a time to do (or to do to a good standard).

FWIW, the aTbRef page on Tinderbox Documentation And Other Resources also links to the above.

1 Like

These are really useful. I am glad you made them: I was almost giving up with TB before I find these.