Holidays approaching: Sharing Themes .tbc files in Tinderbox

File Exchange
1

I understand that .tbc files dropped into the “~/Library/Application Support/Tinderbox/color schemes/” folder will allow you to create custom schemes, however I am still confused how to create .tbc files. I think with the holidays approaching, it would be fun to experiment and share!

Has anyone created some interesting Tinderbox themes for the holidays or would like to share some of your favorite color schemes?

For those interested in experimenting: In the Colors Tab you can customize each color then use the menu on the left to save it as a theme. Of course, for a detailed explanation, one should reference aTBRef.

Here are some from 2019…thanks Bernardo and others for sharing these.

Thanks for sharing in advance.
Tom

2

See TBC files and the Colors Inspector.

As currently described, you customise your colour scheme then use the controls on the Colors Inspector to save the file.

The file is actually just XML, so if you understand XML you can view/edit the TBC in an app like BBEdit.

1 Like
3

So you can customize your themes with just XML?

4

Yes. It is not required, but as long as you understand XML and edit it correctly, you can adjust a TBC ‘by hand’ via editing the XML.

If doing this Be careful about adding new settings (apart from new named colours) as these may cause the colour scheme to not work or at best the extra settings may not work. The exact list of system settings/colours/fonts that can be customised is not fully documented (as this sort of editing isn’t envisaged as a regular approach to the task. So, if tinkering, I’d suggest making a new doc that shows the colours, etc., you want to check and use that so if a mess up occurs you don’t have to repair your main work files.

The’.tbc’ files are c.70–80 lines of code (they vary as not all include the same amount of settings), but they generally all start like this:

<colors >
<color name="0" color="#7a7978" hidden="0"  />
<color name="1" color="#a19f9e" hidden="0"  />
<color name="2" color="#b8b6b4" hidden="0"  />
<color name="3" color="#c7c5c3" hidden="0"  />
<color name="4" color="#d4d2d0" hidden="0"  />
<color name="5" color="#dedcda" hidden="0"  />
<color name="6" color="#e6e4e1" hidden="0"  />
<color name="7" color="#eeebe9" hidden="0"  />
<color name="8" color="#f4f2ef" hidden="0"  />
<color name="9" color="#faf8f5" hidden="0"  />
<color name="black" color="#000000" hidden="0"  />
<color name="blue" color="#003366" hidden="0"  />
<color name="bright blue" color="#0000ff" hidden="0"  />
<color name="bright green" color="#00ff00" hidden="0"  />
<color name="bright red" color="#ff0000" hidden="0"  />
<color name="cool gray" color="#607080" hidden="0"  />
<color name="cool gray dark" color="#505860" hidden="0"  />
<color name="cyan" color="#006666" hidden="0"  />
<color name="gray" color="#f8fafa" hidden="0"  />
<color name="green" color="#009900" hidden="0"  />
<color name="magenta" color="#660066" hidden="0"  />
<color name="normal" color="#dc490b" hidden="0"  />
<color name="orange" color="#ff8800" hidden="0"  />
<color name="pink" color="#ff6698" hidden="0"  />
<color name="poppy" color="#ffcc66" hidden="0"  />
<color name="red" color="#990000" hidden="0"  />
<color name="violet" color="#330099" hidden="0"  />
<color name="warm gray" color="#787060" hidden="0"  />
<color name="warm gray dark" color="#605850" hidden="0"  />
<color name="white" color="#ffffff" hidden="0"  />
<color name="yellow" color="#cccc00" hidden="0"  />
//...more code

In the above, you’ll see a non-default named colour ‘pink’ has been defined (I use it in the aTbRef TBX).

If you’re familiar with XML, save a TBC file and pen in in a plain text editor (or code editor) like Bookends, etc.

5

Thanks @mwra , BTW is it also possible to do it then just using the inspector menu?

image
image744×878 55.2 KB

6

Absolutely! And that’s the normal and recommended approach.

1 Like
7

Yes but only for named colours, i.e. those in the Color pop-up list in the Inspector. Confusingly at first encounter, those names incliude a set of colours—grey by default, named ‘0’ through ‘9’, alongside the more If you want to set other attribute-controlled colours, e.g. $TextColor, you’d use the System Inspect or and select that attribute and change the value there. In some cases like $TextBackgroundColor the default is set in the doc settings.

The concept is akin to other attribute value inheritance. In colour scheme A, ‘blue’ might be a very dark blue, in scheme B a very linght blue and in scheme C a shade of purple. All notes using or inhibiting the colour named ‘blue’ would adopt the colour as set via the colour scheme.

Note there is no ‘undo’ for a colour scheme. To reset to a new TBX’s defaults, apply whichever build-in scheme you need as described in for the Colors tab of Document Settings.

1 Like
8

Thank you!

9

I’m not normally one who obsesses over appearance, but I do confess that some of these font and color schemes do turn my head from time to time.

If I understand all this correctly, should it be possible to use one or more stamps to set a custom appearance(s) for an individual note, or a selection of notes, which overrides the system defaults?

The use case might be a user who has avoided premature formalization and who has decided later that a particular color scheme would be appropriate for one type of note, while a different scheme is appropriate for another.

I assume that font attributes could likewise be altered on a similar basis.

Just to be thorough, is it the case that the last action is what determines the value of these appearance attributes, save for the fact that changes applied to the at the System or Document level do not apply to notes that had been previously created, only new notes under the new settings?

So, for instance, a stamp is applied to a container of notes that alters appearance of its children. Later, an $OnAdd action is added to the container that also alters the appearance of its children, and the $OnAdd action would alter the appearance of all of its children, stamped and unstamped alike. The $OnAdd occurring after the children had been previously stamped.

I hesitate to ask, but if a stamp is subsequently applied to a note or collection of notes in that container that alters the appearance of those notes, does it override the $OnAdd action? I have the impression that it would. Tabbing or dragging a note out of that container and re-inserting it would then invoke the $OnAdd action and its appearance would be altered again. Is that correct?

Just to get all squirrelly here, it seems at least theoretically possible to have $OnVisit check the current time, and if it fell within a certain window, apply a theme that is somehow appropriate for that period by means of an “if…then…else” construction.

I suppose I should just try all this in a test file, but this discussion has prompted these questions and perhaps they add to the discussion. I hope so, anyway.

10

All of this makes sense.

For example, consider a note named Bob. Normally, Bob’s color is the default value of $Color. But $Color can be set inherited from a prototype, or changed by an action.

One complexity is the question of text formatting in the text pane. The text formatting attributes determine the text style for new notes, but Tinderbox is cautious about changing text styling in notes that already exist. Those notes might have styles applied for a good reason, and just changing them might cause mayhem. But if you do set $TextFont to a new font, notes that have text in the format $TextFont will change to the new $TextFont automatically.

1 Like
11

I think we’re confusing two aspects of the app. Colo(u)r scheme files (.tbc), see here and here, control named colours, see here and here.

Essentially, a .tbc alters/adds to the initial named colours in a new file. So ‘bright blue’ might start out as a bright blue but another colour scheme, when applied might—for aesthetic reasons—set a colour value of blue-green for the colour still named ‘bright blue’.

I don’t believe action code can alter the defined value of named colours, though they can be altered manually via the Document Inspector’s Colors tab.

Separately, an action or prototype inheritance may set the value of a Color-type attribute, e.g. $Color.

Changing the colour scheme of a TBX will likely make the TBX look different but doesn’t directly change any, for instance, $Color value. But if scheme A and scheme B define the same named colour ‘red’ differently, any note with $Color set to red will appear to change colour.

So…

Yes. As explained about, the scheme simply sets the current TBX’s colour value for any named colours. So a note may be red ($Color="red") and it will be whatever colour is defined for red in the current scheme. If I set $Colour to #123456, the locally-set value is used. ‘red’ stays set to the same doc-level value but just is not used by this note.

Conversely you can’t have 3 different notes all with $Color="red" but have them show a different colour. Why? Because the colour scheme is *whole document scope`.

A few gotchas to consider:

  • Not all schemes define all colours or ancillary attribute like $TextBackground colours.
  • If a scheme contains a new named colour not in the current TBX, that colour and value are added to the TBX
  • If a new scheme does not contain all the named colours in the current document, the ‘unused’ colors persist whilst those in the new scheme may be given a new colour value
  • Thus a scheme can add colours but not delete them.
  • Some schemes set more ancillary fields that others, so altering colour scheme, may required some additional triage of document system attribute color-type attributes.

Also, colour schemes work best (IMO) in map view. So the muted colours of the ‘Modern’ scheme look fine in a map but in an Outline, they look muddy and hard to distinguish. The ’ Tinderbox 7’ scheme is likely the most useful for Outline work where there is deliberate meaningful use of colours with $Color. However, you cannot set per-view schemes, just as (above) you cannot set per-note schemes.

1 Like