Glyphs’ ability to auto-detect when a UFO was changed, and to ask whether to reload it, is an incredibly useful feature for the project I am working on right now.
However, when I work with UFOs in Dropbox and save the UFO from Glyphs then I always get “The file for the document at XXX.ufo has been modified by another application. Do you want to reload the version from disk?”, several times. Even though it was just saved by Glyphs.
Looks like Dropbox somehow “touches” the changed files in a way that makes Glyphs think they have been modified. I am not getting the warnings when Dropbox syncing is paused.
Could this be fixed? Maybe using a different indicator to determine whether the UFO was modified by another application (e.g. file modification dates or even content comparison)?
Or, at least “group” the warnings so that I am not getting multiple warning dialogs when Dropbox touches several files within the UFO?
Does it have to be Dropbox? I have heard from several UFO users that Dropbox is too slow for UFOs, and syncing can take up to several days if you’re overwriting the many files in the .ufo subfolders. Perhaps the error messages are related to that deeper inherent problem? Just guessing though.
I have heard of the problems with UFO in Dropbox, caused by the many files they contain. Easy to imagine why this causes slowness.
However, for my current project, this is not a problem because I am only changing two or three files at a time.
As I wrote above, the problem is that Dropbox seems to touch the files in a way that makes Glyphs think they have been modified. This is unrelated to the fact that UFOs often contain a large number of files.
I’d say touchshould trigger the modification warning in Glyphs, it even changes the modification date (as seen in Finder).
However, whatever Dropbox does is not the same as touch (this is why I used quotes in the beginning) because Dropbox does not change the file modification date. Is it just opening the file?
@georg, maybe on your computer you checked “Do not show…” at some point in the past? This could be the reason why you cannot reproduce the problem.
Could it be that Glyphs starts writing the files in the UFO, which takes a while, and later considers a file it has written itself as modified (by another application)? How is the modification determined? Maybe the timestamps are handled inaccurately? It could be that using Dropbox is not the actual cause but only reveals the problem.
