I’d like to set up links to favorite documents in the favorite folder, as described in aTbRef.
However, I can’t seem to get this to work, here’s what I tried:
When I put a document or an alias to a document into the favorites folder, Tinderbox opens an unnamed copy of that document. (The files are not marked as stationary pad)
When I put a symlink into that folder, it shows up in the favorites menu, but the document won’t open.
When I double-click either of those in Finder, Tinderbox opens the correct document, just as ist should.
I am clearly missing something important here, but I can’t seem to figure out what that might be.
My understanding is that currently the ‘favorites’ folder supports a TBX or an alias to a TBX placed therein. I’ve never seen anything to suggest symlinks are supported.
The OS ‘stationery file’ flag may be a legacy issue. Previously this was needed, but I think that reflecting the fact that OS feature may not survive, it appears that all file in (or aliased in) the ‘favorites’ folder as treated as if a stationery pad. IOW, it may be you can’t open a file for normal edit via the File -> Open Favorites -> sub-menu. I’ll check and report back.
Symlinks in folders in ~/Library/Application Support/… are flakey under Mojave and Catalina for some reason. At least, that’s what I’ve observed over the past year or so.
Opening a document from Tinderbox > File > Open Favorites creates a new, unsaved copy of the document selected from that menu. Best practice is to first save that copy into your working folders, then proceed.
Not sure why you would need to link to documents in ~/Library/Application Support/Tinderbox/favorites. The documents there are just starting points for “real” working copies. It’s not a good idea to be storing your work in that folder.
I am on High Sierra. It is beyond me why symlinks in certain locations should behave differently from symlinks elsewhere. But then again, with recent versions MacOS lots of weird stuff happens.
As I mentioned above, aTbRef explains that differently. I might add that this is the common usage for the term “favorite” in apps, a place where you store things you often use, think of the favorites in your browser, in the Mail app, or in Finder. For the use you describe, I would expect this to be called “document templates”.
Indeed, and that is why I tried to use aliases and symlinks.
The problem is that, while you can set the flag, there’s no longer a way for Tinderbox to learn that this file is a stationery pad without using a deprecated API/
This is a weird corner of AppKit. I assumed it was transient — a side-effect of the shift to APFS — but the issue has persisted for years.
FWIW, as part of the refresh for v8.1.1 I’ve updated the aTbRef notes on this folder to clarify that it now acts as a stationery file source rather than a place for most-used files.
I’ve 100s of TBXs on my system, plus those users post here for problem solving. Nonetheless, I generally find my regular files stay in my recently used list so I don’t really need list just for favorites. The stationery file angle I do use a lot as I generally use my ‘starter’ file when testing forum users’ problems.
Well, if you really want to make it work programmatically, you might run the mdls command on a file in terminal, parse the output for the value of kMDItemFSFinderFlags and see if the result contains the flag for Stationery Pad (2048). If so, you could duplicate the file and open the copy.
I do think there’s a point there. Then again, I don’t want that guy and say it’s al wrong. The folder is called ‘favorites’ but _functions as ‘stationery’. This isn’t a deliberate mis-step by Eastgate. Stuff changes: when first implemented, the folder supported favourite and ‘recent’ files.
For my 2¢, I’d suggest renaming the folder ‘stationery’ going forward whilst supporting the older ‘favorites’ folder for us long term lags (and those who don’t want to dive under the hood to clean up.
A pivot point arrives. I haven’t updated to Catalina yet. Updates are cool, but all my old games (Steam) die and a number of useful 32-bit niche utilities die. I’m old, so younger!+sexy by default. IOW, it’s too easy to dragoon Eastgate to a change. But, going forward I’d rename - or rather - add a better-named folder (in context, oldster will still have a v5-era ‘backups’ folder) and support but deprecate the ‘favorites’ folder.
FWIW I recently acquired a tiny (1.8") used 128GB SSD from Toshiba in atiny metal case, which is fast enough to boot High Sierra and play all those 32bit games. I have a bit of velcro on my Macbook’s lid to attach it to, and a really short cable, so it’s not even an nuisance on a train or so.
It only took a couple of minutes to clone the relevant parts of my MacOS installation via CCC, and I found it also helps my productivity that I now deleted all games from my main MacOS. Best €50 I ever spent on hardware.
gosh - 3 years back. I think the latest relates to possible confusion over favourite files (IOW, thinks I’ll want to open regularly without hunting in the MRU list) and stationery files (where new copy is opened). ISTR there was some debate about stationery vs not stationery file use.
Essentially, some might argue for 3 discrete lists:
MRU (most recently used) files - whatever i’ve opened recently
‘My’ files - one i’ll want to open regardless of MRU listings
Stationery files - where I do want a copy and not the source file
I think we that #1 and #3 only at present. A partial factor is/may be changes in the OS’ attitude towards stationery files. It would seen these are a tolerated legacy feature rather than something the OS really wants to support.
#2 probably affects few users. My current MRU seems to show 17 recent items. this might seem a lot, but do some file versioning and have a day with a host of forum questions needing test docs† and ‘my’ docs (category #2) has rolled off the list and I have to go hunt for them.
Not sure if that clarifies any.
†. This is why I try not to save test docs if I can otherwise my MRU list becomes less useful than it might be. But, I suspect few have this same problem.