One-sentence answer: Authors can treat .inform as a single file, whereas .materials is a directory that authors poke around in. Therefore all the user-serviceable parts go in .materials; .inform has all the stuff which is only manipulated by the IDE.
Okay, two sentences.
It’s not pandering; it’s a user-friendly organization which unfortunately is only supported by the Mac Finder. If Windows could do it, we’d want to support it there too.
A hidden .build folder would accomplish the same, right? And that could be implemented on all 3 OSes.
A hidden build folder would be reasonable for .inform/Build and .inform/Index. But the other stuff (story.ni, uuid.txt, settings, skein, etc) is not build products. It’s meant to be kept together and edited as a unit.
I suppose the non-Mac-centric form of this is “zip file containing story.ni, etc”. But then you piss off everyone else – people who use source control, external editors, or anything else that peeks into .inform.
My use of “pandering” was obnoxious, and I apologize for it.
That said, I could understand a rationale for divisions based on any of:
What we actually have is:
project.inform:
source files: story.ni, uuid.txt (I’m going with “source file” for uuid.txt even though it’s by default generated by the IDE and isn’t typically something the user would edit)
reproducibly generated, disposable things: Build dir, Index dir, Metadata.iFiction, Release.blurb
programatically generated, but not reproducible if it’s deleted: the Skein
sort-of source file, though significant only to the IDEs, not the compiler itself, and not intended to be edited by the user: Settings.plist
project.materials:
source files: project_metadata.json and any amount of stuff in Extensions, Templates, Language, Figures, Sounds, Files, Inter, and, in the forthcoming version, Source
reproducibly generated, disposable things: Release dir, EPS file, things under Extensions/Reserved
I’m hard-pressed to see the user-friendliness or any coherent rationale for this division.
[edited to add Extensions/Reserved]
The idea is that to the average user, the .inform bundle is a single source file, the equivalent of an Inform 6 .inf file. Ideally, there should never be any reason to look inside the bundle at all, it is supposed to be handled automatically by the IDE. The stuff in the materials folder, on the other hand, are things that the user has to deal with on a file-by-file basis.
Sure, we understand that. But it’s a solution that only works in one OS. And it makes things considerably more messy for anyone wanting to use source control.
The goal could be equally accomplished through hidden folders. Perhaps multiple hidden folders would be most sensible, so that reproducible things could go in .build, and important metadata/settings/etc could go in .metadata. Then .gitignore would only need to ignore .build.
I suppose these hidden folders are still inside the .inform bundle, right? So it is really just a reorganisation of files inside the bundle that is needed.
The ideal IMO would be to only have one folder. There would be no MacOS style bundle, and the folder wouldn’t even need to have an .inform extension (unless that helps for file associations? I’m not sure folders can have associated apps except in MacOS.) Then inside that would be story.ni, the Figures, Extensions, Release, etc folders that are intended for the author to access, and as many hidden folders as makes sense to organise things well.
That sounds good: a single project directory that’s mostly like .materials, but with Source/story.ni, hidden folders for Build, Index, Skein, a new hidden Config folder for uuid.txt and Settings.plist, and maybe put Release.blurb, Metadata.iFiction, and any generated EPS files in Build.
I think that means you would lose the ability to double click on a file (the .inform bundle) at the top level to open a project, which would be annoying.
This might be solved by introducing a new file type, something like Project.inform, equivalent to the solution (.sln) file in Visual Studio, which opens the entire project.
Having a top level file/bundle/bonus-folder (depending on your perspective) next to - and thus outside - the folder that contains the rest of the project is a big part of what causes friction whenever an inform project is handled by anything other than the Mac app. As others have pointed out, source control and many other tools expect to focus on files nested below a single top-level directory, and for this reason I’d still prefer it to change even if I used a Mac for Inform stuff too and not just for my day job (although I’m an avid user of source control and command line tools, so I’m not representative for authors in general). I think that’s the main part where the current layout makes a questionable trade-off.
If there was a single folder for each project, with something inside that one can double-click on to open the project in the IDE, that seems like be a perfectly acceptable user experience for all users on all operating systems. It’s not like this would be a foreign concept for Mac users in particular. In fact, I have not encountered this “file (bundle or not) + adjacent folder with similar name” layout anywhere in the couple of years I’ve been using a Macbook. Case in point: Apple’s own XCode IDE uses such a “single top-level folder containing both a clickable project name.xcodeproj and sub-folders” layout.
Everything else - how exactly the contents of the project are organised into subdirectories, whether some of it appears as a bundle on Mac and a oddly named folder elsewhere, which parts are shuffled away into hidden folders, etc. can probably be bikeshedded into a form that’s good enough for everyone (leaving aside that long time users will have to change some habits - but this applies more or less to any significant change). After all, every program that deals with a bunch of files in a directory - and not just a single file - has its own idiosyncratic layout conventions. But having two top-level things instead of a single folder sticks out as something that only makes any sense for the Mac IDE and is plain weird everywhere else - including any use of command line tools on Mac!
(This is not to advocate for just shoving each pair of .inform and .materials folder into another layer of nesting - this is what everyone using source control already does and it kinda sucks. The second step of reorganising the project contents - e.g., properly separating temporary build outputs from stuff that authors add and edit - is necessary to actually improve things.)
I agree that it is not ideal, or even particularly Mac-like, to have two Finder items (Project.inform bundle and materials folder) rather than one, and that the sensible thing is to organise them both inside a common folder. My point is really that it is convenient to have a single file that you can double click to open the project, something which seems to be currently lacking on both Windows and Linux.
as *nix user, I think that story.materials should be part of story.inform, but this is a mere shifting from mac style to unix style, opening a different can of worm.
Best regards from Italy,
dott. Piergiorgio.
Right, I don’t think this is currently supported by the Windows or Linux apps and it might be nice polish. There’s many ways to achieve this, it doesn’t even have to be a whole new file. A file association for existing files with reasonably unique extensions (say, *.ni) could already work with today’s layout, it’s just more convenient if such a file is immediately visible in the project root (unlike story.ni today). And by the way, none of that has to conflict with Mac users being (also) able to click on a bundle to open the IDE, if there’s reasons to prefer that over a plain file association. As always, non-Mac users will see a folder, but depending on its contents, they may be able to mostly ignore it.
The current behaviour when double clicking a story.ni file is for it to open in a separate window in the IDE, rather than opening a project, which is kind of nice. I think a new kind of dedicated project file would still be preferred.
In the Mac IDE, that is? As I was writing my last post, I tried and failed to convince the Windows IDE to do anything when I “Open with…” an *.ni file with it. But you’re right that there’s other behaviors one might want than what I suggested off-hand. There’s gonna be some broadly agreeable way to lay out the contents of a project in a single root folder - but it’s all conditional on the decision to adopt a single root folder.
Is this MacOS behavior of opening the project when double-clicking the .inform folder only available if it’s a bundle? (If so, at last I see why it could be considered a feature.)
Couldn’t the same user experience be accomplished, though, by creating single file launchers on a per project basis, and letting the IDE show those to the user, and have it create a new one when a new project is created, but have the actual project contents elsewhere, with the real location baked into the launcher? (I’m talking out of an other-than-the-conventional orifice here, obviously, being a Mac ignoramus,but this sounds like something plausible to me.)
Scratch that, an author would want to interact with it directly. Maybe a new Maps directory.
And I forgot poor manifest.plist. That one does seem like another decent candidate for Build.
It can’t simultaneously be something that you can click to launch a program (similar to an ordinary file) and a folder that you can click on to navigate inside. While it’s possible to open a bundle as a folder in the GUI, you have to know it’s a disguised folder and find the menu option to open it as such. So just having a single bundle without a separate .materials folder would make it more difficult and annoying to directly work with files in what’s currently the .materials folder. (For the same reason, I think it’s currently more difficult on Mac than elsewhere to grab files that are only output to Project.inform/Build, such as gameinfo.dbg).
There’s nothing inherently wrong with such shortcuts (to use Windows terminology), but I think they work best when users consciously create them and are always aware that they’re just a link, not the real thing. Otherwise, it’s easy to stumble over the subtle difference when they matter, e.g., moving the actual project around will likely break the launcher, while moving / copying / sharing the launcher does not actually move / copy / share the project. The current .inform/.materials split is somewhat less subtle, you just have to remember that the Project.inform “file” is not the whole project but goes along with its sibling Project.materials.
Another difference: if launchers are in their own dedicated folder somewhere, authors would have to juggle two separate locations, i.e., specifically navigating to the launchers’ location just to open one of the projects, then have nothing else to do there and still having to go to (what is currently) the .materials folder. In that case, I don’t see the advantage over more conventional approaches: go straight to the project folder and click a file in it, or open the IDE and go by its list of previously open projects. (Or manually creating a file shortcut in a convenient location, although I’ve had to google how to do that, so maybe it’s a power user feature.)
To test my understanding, the up-sides to the current scheme are:
Mac IDE users using the Finder to locate a project get something they can double-click to launch the IDE. (Does the scheme help anything if you’re opening a project once you’re in the IDE?)
For Mac users, it inseparably bundles the contents of the .inform folder so that the user can’t make the mistake of moving one file out of place or copying one file and thinking they have a backup… though if they’ve put any Extensions or Images or whatnot in .materials, they still don’t have a backup if they copy just the .inform bundle.
Is this missing anything?
As a Windows user I was unaware that on a Mac the Inform folder appeared as a clickable icon. I regularly copy the story.ni file into a duplicate folder structure on the cloud to make a backup. I’m aware that doing this doesn’t back up other data such as the skein, but it’s never caused me any problems!