Clearly the status quo evolved over a long period. In the early days of I7, materials folders seemed less important than they do now.
I entirely agree that it’s awkward for source control that there’s no single root directory for a project, though of course users are free to make one if they want to.
And I agree also that the current design, which sequesters hidden things from the user in .inform, to make a clickable bundle in the MacOS file system, while having user-accessible parts (some you want to keep, some disposable) in .materials, is motivated by MacOS.
But there is also a further consideration. The virtue of the .inform bundle is not just to make a nice opaque file-like object for users. Apps on MacOS are increasingly locked down by security considerations, and do not have general file-system access. The Inform IDE for MacOS is only able to read and write the materials folder because it has an identical leafname to the document (i.e., the .inform bundle). By clicking on that document, the user gives it permission to access these two folders. (This is all a compromise in MacOS based around the needs of subtitling files which typically sit alongside video files, so that video players can access subtitles without violating the sandboxing rules.) Windows is moving in this general direction, too, as I understand it. I think the days when consumer operating systems will allow users to download and run apps with full file-system access are pretty well gone.
It is all a bit of a cat’s-cradle of compromises. What is ideal for a command-line user whose natural home is Github is not what is ideal for a casual writer whose natural home is the Finder in MacOS. But command-line people are better able to cope with the inconvenience, I think.
So, if the motivation is to have user-accessible parts in .materials – there’s a couple of key places where that’s not what’s happening right now, especially the main source code file.
If we could just get all the directly-author-modified files on one side, it would help a lot with source control and command-line maintenance. These seem to be moving towards .materials, what with subsidary source files being in game.materials/Source on the latest version.
Getting the main source file out of .inform and into .materials would help the most. If I could get rid of the MyGame.inform/Source/story.ni file, and instead have a MyGame.materials/Source/MyGame.i7 file (with the same base name as the project), that would be excellent and would eliminate the largest hassles. It would mean I don’t have a zillion “story.ni” files floating around, differentiated only by what directory they’re in; it would get back to the programming tradition of having source code files with meaningful filenames.
Moving the uuid.txt file, which occasionally has to be manually edited (if I start a new project but in fact it’s really the continuation of an old project) would help too.
I would be open to allowing MyGame.materials/Source/MyGame.i7 as an option, though of course it requires changes to the three existing IDEs to do that. It probably can’t be the default, from the point of view of beginners. I worry a little about people having the file open in both the IDE app and also a text editor simultaneously, and then races between saves.
I’m less persuaded about uuid.txt. For that, it might be better for the IDEs to have the option of changing the UUID.
Thanks. Honestly I think anyone who’s been using a computer to create anything at all and opens multiple programs at once should be fully aware of race conditions on saves, since it comes up with basic word processing, image editing, and spreadsheet stuff pretty routinely. The best you can reasonably do is along the lines of The file has changed on disk since the last time you loaded it, are you sure you want to overwrite it? – which most text editors are quite good about, and the IDE should probably do that too.
On the potential race (I prefer the term “inconsistency”, whose depict better the specific situation) I generally use an external editor+ a tiny adhoc shell script of mine for compiling, but when I need a D version, I close the editor, and start the IDE (this allows me to have the font size I want…) for compiling & debugging (of course, the binaries are separate, thanks to the shell script…)
On the general issue of mac and windoze’s questionable trend, I warmly suggest to switch the main development under Linux or a *nix environment, and porting for the other two “operating systems”; IIRC, Graham, you’re an academic in the field of mathematics, so, you surely know how to work in a *nix environment.
I wrote all of Hadean Lands this way. The lack of IDE support for it was a headache.
The standard strategy (which all modern external editors already support) is that when the app gets focus, it does a quick stat() check on all open source files. If the file has been touched and the window has no unsaved changes, you silently reload the file. If there are unsaved changes you ask the user which version to use.
EDIT-ADD: You need to support this anyway as soon as people start using version control on IDE-displayed files. Which we do.
I don’t think IDE changes would be necessary to enact the scheme I suggested on inform-evolution by which one could declare an alternative story file in project_metadata.json. (Well, you would want the IDEs to be able to edit things under project.materials/Source, but I figured that was already implied by IE-0003.)
In the above, I also suggested allowing the uuid to be specified in project_metadata.json.
This approach has the advantage of having no effect on the status quo for people disinterested in isolating source data under one directory for convenience of source control.
Off topic, but macOS bundles are actually a very good idea that solves many problems, and all operating systems should implement support for them. Once that is done, we can replace file formats that are difficult to read and modify, such as Blorb and Quetzal, with bundles.
While that would be an interesting world, I don’t expect to see it, so I’m not going to worry about the details.
Even MacOS does not support the idea at the operating-system level. (You can’t transparently cp or scp a bundle.) You’d need at least that much support to really commit to the idea as a replacement for single-file solutions.
The rest of the computing world seems to have settled on using archive formats for that purpose (e.g. a word .docx file is really just a ZIP archive with specific contents).
That is nowhere near as convenient, though. A lot of the time, you will have to decompress the entire file to access the contents, especially if you want to run binaries inside. The nice thing about bundles is that they really are just folders, easily accessible with all the usual file system methods.
I thought I remembered this didn’t work anymore in 10.1, but I just checked and I was wrong:
You can use a directory that doesn’t end .inform as an Inform project directory, and if you do, it will look for the stuff that’s ordinarily under project.materials in that directory. i.e., after a compilation, its contents might look like:
Build
Extensions
Index
Metadata.iFiction
Release
Release.blurb
Source
manifest.plist
uuid.txt
So far as I know, this won’t work with any of the IDEs and it also no longer works in the current development version.
[ after some experimentation, it does still work in dev if one comments out all of the new code that audits the project for extraneous files (that I suggested to Graham) ]
I find the auditing for extraneous files extremely irritating, as it makes it hard to add “extra arbitrary stuff” for my own internal development use (READMEs, design notes, etc.) so maybe we should comment some of that out anyway…
On the bright side, if you’ve created a parent directory over .inform and .materials for source-control purposes, you can put all the extra arbitrary stuff there!