I accidentally closed tabs, saved and closed a font. Luckily, I had backups, which I restored because the tabs were important to me. However, when I opened the old font, the tabs were gone! Using a font where these tabs are definitely saved (checking the file in a text editor). Out of desperation, I opened the file on a different computer and there they were, the missing tabs!
What was happening?
Is there some weird, “smart” handling of tabs going on? Is Glyphs failing to read them correctly from the file? Does it think it is really smart and tries to remember the tabs somewhere (intransparently) other than in the file?
There are two places where tabs are stored. In the file for sharing (via mail, Git, Dropbox, etc.) and as extended attributes as part of the file metadata. Glyphs prefers the latter as its representation is a bit richer than the plain text tabs in the file.
It appears you used a file recovery method that restored the old file contents while keeping the current metadata. That sounds unusual to me. Was it Time Machine or some other recovery tool?
There is a lot of UI state that is stored in the metadata of a file. For tabs, that includes scroll position and zoom level, among other data. So, for DRY-purposes the tabs would not be written to the file contents. But, this tab text info is important enough to many users that we also write the plain text tabs into the file so tabs are also shared when the metadata gets lost (again, mail, Git, Zip, etc.). Now that the tabs data is in two places, Glyphs has to pick one of the two and the one in the metadata is richer in information, so it is preferred.
Where are the file metadata stored? Wouldn’t it make sense to store all the metadata in the file? I doubt anyone would consider it a bad thing if Glyphs were able to restore not only tabs, but also scroll position, zoom level, etc. even across computers, at only the expense of (I’m guessing?) a fairly small increase in file size. Perhaps with a setting/function to ‘scrub’ a file of metadata if you want to send a ‘clean’ copy to someone else.
The extra data of the tabs is not that big, but there are many more infos stored about the entire UI state of the app/document. That would create a lot of noise for file diffing, version control, and other use cases that compare file contents programmatically.
I understand you had a bad experience because the file recovery method you used only restored the file’s contents and not also the file’s metadata, and also did not substitute the file as part of the recovery, thereby keeping stale metadata associated with restored file contents.
A solution would be to check the metadata and file contents for agreement on the tab strings and, in case of disagreement, pick the file contents over the metadata. However, that heuristic might only exhibit the correct behavior in this scenario and the opposite would be required in a different scenario.
The disagreement between the two tab representations has not caused much issues yet, and I am still unsure how this specific situation arose, so I would prefer to avoid smarter heuristics until we have more certainty that a potential fix is not creating more issues than it solves.
That is unavoidable. If the file data say only tabs A and B are open, and the metadata say only tabs C and D are open, there is no possible way for Glyphs to honour both. When two instructions contradict each other, the only options are to choose one over the other (ignoring one) or do nothing (ignoring both).
It would perhaps be an improvement if the app were to let the user know that the file data and metadata conflict and let the user actively decide which to use. That would still ignore one or the other, but it would do so at the user’s discretion, rather than by a predefined preference list.
It’s quite simple, isn’t it? If we are considering situations in which Glyphs can (has to) pick then it will ignore the other, and this ignored data can, obviously, be either the metadata or the file contents. Saying “The metadata is not ignored” is an absurd way of contradicting this reasoning.
Since the current order is that metadata is checked first, it is perfectly accurate to say that metadata is not ignored. The tab data in the file data is ignored if it’s present in the metadata, but the metadata is never ignored (if it’s there). That’s precisely why your tabs where lost: the metadata was not ignored.
In theory, the ignored data could either be from the file or from the metadata, but in practice, only file data will ever be ignored.