I find myself having to do a lot of tedious setup whenever I start a new TBX file. Prototypes, often used functions, fonts, etc. Is there a way to start a new TBX file with certain defaults, or is there another approach I’m missing?
Everyone has different needs, so the long-standing solution (since c. v5.5.0) for those with particular non-app-default starting configurations is to use the ‘favorites’ support folder: see more.
So, make a file with your desired customisations, stick it in the ‘favorites’ folder and call it from the File → Open Favorites menu. Job done!
Exactly what I was looking for. Thanks!
Tinderbox uses shortcut ⌘N to create a new default file.
With the free CustomShortcuts app it’s possible to reassign shortcut ⌘N to the favorites menu, so that this shortcut can then be used to open a new preconfigured file instead of Tinderbox’s default new file.
To do this in CustomShortcuts app
- add application Tinderbox
- create a new entry for menu
File->New- assign a shortcut, e.g.
⌥⇧⌘N
(in order to make the⌘+Nshortcut available for your favorite file)
- assign a shortcut, e.g.
- create a new entry for menu
File->Open Favorites->My default Tinderbox- assign shortcut
⌘N
- assign shortcut
Note: CustomShortcuts uses special arrows, the one I used in e.g. File->New doesn’t work if you paste it into CustomShortcuts. If you start typing the name CustomShortcuts will automatically suggest the correct arrow.
1 Like
My take away from this is perhaps aTbRef might benefit from a new (short) article about customising the ‘new file’ result. Essentially, use of ‘favorites’ plus the possibility of custom shortcuts to one’s desired customised starting file. A separate article means it can be linked to from relevant places (and more easily found via search).
Would this be helpful?
3 Likes
I think it is pertinent to observe here that the Favorites are for template files and not the actual/active files that users like to keep handy. I made that mistake OUAT and ended up with a bunch of duplicated and messed up data lol
I made the same mistake. I think the term “Favorites” is a bit misleading. Really they are “Templates”.
Indeed, I think the title of the feature is—*unintentionally—misleading. Users needs vary. My recently used files list 30 items long. But, for instance, a busy day of forum questions and beta testing often rolls my favourite files off that list. I believe the original idea of the favourites was a place to put items one wants to always have close at hand. A some point the desire for a custom template (stationery) files got cross-threaded with the current result.
In hindsight, I think favourites should be omitted from the MRU list, training the user to open favourites from that menu and everything else from open. Then again, I’m sure that apart from tests, plenty of users have one TBX file (q.v. my system has >600, albeit some if dark corners for storage rather than routing use).
AI had focus at present but this reminds me that ‘favorites’ are perhaps due a review.
If we are to do a look into this topic, my high-value contribution is that we allow for the addition of a sub-menu called “workspaces”.
Excel used to offer this, and it was incredibly valuable because I could save - and position onscreen - all the worksheets pertinent to a specific project. Saving the workspace would also save individual file states and window sizing, to be recalled as a group when I was ready to deal with that project. I never had to trouble with rolled-off recently opened files, either, as I simply maintained 3-4 workspaces for all my active projects.
The ONLY issue I had was that one-off opened files were occasionally accidentally included in a workspace - which was of course easy enough to fix.
Obsidian offers a similar feature, also called Workspaces, that saves user layouts (files are auto-saved anyway) only. I use it on occasion, it’s a good timesaver especially when switching from desktop to travel working.
As Tinderbox moves toward increasing data-sharing between files, I can see a use case for workspaces here.
1 Like
If you close a TBX and reopen it remembers where its windows (document and stand-alone). Each document does this for its own windows. What is the problem the ‘workspace’ would address?
Given that Favorites opens a copy of the file, I would argue that Favorites is almost certainly the incorrect label. I hear you on “Users needs vary”, but in my eyes if it was actually a Favorite, it would be simply a specific, preferred TBX file that I want surfaced to the top regardless of how frequently it’s accessed. And it would open the file, not a copy.
Just to be clear: I would like both! A Favorites and a Templates option. Favorites would be files that I… well… really like and Templates would be files that I want to use as foundations for new files.
I would have never guessed that Favorites in its current form was what it was. Thankfully the forum is amazing here (especially you Mark!), but I think if it was labeled differently, it would make much more sense.
1 Like
Understood. I suspect this will get kicked around on the Backstage a bit as it’s invariably hard to find a solution that pleases all. :). At least we’ve updated people on current behaviours.
The usage can vary in that a workspace remembers each file and its specific location on your display, which makes it easier to re-load groups of files with everything in its right place. Clearly there might be some confusion if one is loading only one of the files in a workspace and moves/resizes it, then subsequently loads the entire workspace. I’m sure there would be things to work out in implementation, however the general idea of a workspace is appealing to my usage scenario.
1 Like
Is this different presentations of the same file, or groups of files?
Groups of files.
It’s an interesting question relating to Tbx, due to the nature of simultaneous window updates to all open copies of a particular file. In fact Obsidian does this quite well, albeit differently from Excel-of-yore. I can demonstrate at an upcoming meetup.
2 Likes
You can also build yourself an installer.
And, you can put your prototypes in the applications support folder and they’ll be added to each file. Honestly, I find the installer scales better. Take a look at my 5Cs demos and you can see the installer in action:
- TBX 5CS Lesson: 5Cs Tinderbox Advanced List View
- TBX 5CS Lesson: 5Cs Tinderbox Advanced Internal Text Anchors Template
- 5CS TBX Lesson: 5Cs Is No Show Convention (a.k.a., Envelope or Letter Idiom) for Templates
- TBX 5CS Library: 5Cs Tinderbox Dynamic Note Creation, Linking, and Unlinking Library Overview
- 5Cs TBX Media Library and Templates Overview
- 5CS TBX PDF and Pandoc Publishing: Libraries and Templates (Video)
- 5Cs TBX Glossaries, Indexing and Numbering Libraries and Templates
1 Like
I think the difference of a customised ‘new’ file and an installer is one of scale of customisation—and partly the type of work(s) done.
If just setting up a few attributes/prototypes then a customised stationery file in /favorites. This likely covers most users, especially those just starting out with Tinderbox.
From use it may become apparent through ongoing use that one has one (or more) processes that involve a much higher degree of customisation. Since the advent of action code user functions (in v9.1.0) it has been possible for expert users to write installers, the core of which is custom action code library files.
Happily, the result of this is an installer that will customise a default new TBX file so even a new user can get to work using the custom design. Be aware though that understanding the code installed or trying to customise it generally remains an expert task, though those making installer for wider use do document their work and provide user attributes so there can be some easy tick-box customisation of elements of the installed process.
You might ask, why not just put all the custom libraries in a custom ‘favorites’ file? Yes, that is perfectly possible. So where does an installer make sense:
- As a user without action code expertise, an installer it allows one fast access to process complexity one cannot build oneself. Happily, there are those in the community happy to assist. some installers are shared for free, some are a purchase. In the latter case, note that installers can be a lot of unseen work—especially if there is an expectation that ‘someone else’ (usually the installer 's creator) will support/update the installed code as the app and its host OS evolve. An installer is much more than just changing a few attribute defaults.
- If an installer can re-install update a file, this allows files with other content to be kept up to date
- As a self-contained set of file(s), the installer is probable without having to consider wider customisations of a whole TBX document.
- Installers may well centre around a particular task or process and so it is possible to use multiple installers in one TBX (assuming the installer designer had that possibility in mind—it’s yet more code work for them)
- Creating an installer is not suggested as a first action code learning project.
- Mixing your own basic document customisations with an installer-generated complex customisation is perfectly possible.
1 Like