[I7] I7 projects and bundle files

[Jesse McGrew]

On Dec 30, 2007 5:17 PM, Andrew Hunter <andrew at logicalshift.demon.co.uk> wrote:
>
> On 31 Dec 2007, at 00:19, Jesse McGrew wrote:
[...]
> > Inform 7 projects currently stick out like a sore thumb among all
> > other document types. What other program saves its projects as a whole
> > folder, except for Mac-only programs where you can't tell the
> > difference without looking closely anyway?
>
> Actually, that's easy to answer: pretty much any IDE works like this
> due to the necessity of having multiple source files. This is really
> where Inform's file structure design came from, especially as it
> supported multiple source file projects up to a few weeks before
> release (in fact, it still does support them: the UI is merely hidden).

Fair enough. But note that other IDEs don't present the illusion that
the project is a single entity. Visual Studio makes it clear that the
.sln, .csproj, and .cs files are separate entities, and doesn't
require them to be in a particular directory structure.

Also, it uses unique file types for the project (.csproj, etc.) and
project-group (.sln) files, and puts them at the top of the structure
where they're easily accessible. That means there's *something* you
can double click on in Explorer to open the project, without having to
open the IDE first and then navigate to the project.

Finally, while this structure makes sense for multiple-file projects,
I7 in its current form doesn't use multiple source files. From a
user's perspective, an I7 project is just some source text and some
settings.

> A folder based solution allows the contents to be presented as text
> files that can be easily interpreted by other utilities. Source
> control springs immediately to mind: I imagine that it's not the only
> reason to want to see the contents of the project in a simple form; by
> using such a format we're really limiting manipulation of the contents
> to the IDE and the compiler - certainly you would need to be
> determined to write a third-party tool to alter or manage a project's
> source code.

Also fair. However, these would be mitigated by leaving in the option
to save projects in uncompressed form.

So far, I'm not aware of any tools that need access to the innards of
I7 projects, and I think using a standard archive format like zip
makes it fairly easy for third-party tools to read it.

> The additional complexity required to do this concerns me as well. The
> compiler does not produce a single output: it produces a fairly large
> collection of output files that are processed by the IDE. At the
> moment these are written into the project directory which means that
> the IDE just needs to tell the compiler where the project lives, let
> it update it as it will and then update itself when it's done. This
> isn't possible with a single file solution: because the user can still
> perform edits while the compiler is operating it would be a recipe for
> disaster.

Why not prevent the user from editing/saving while the compiler is running?

> I think that something that has also been missing from the discussion
> is the nature of the 'materials' folder: as long at it exists this
> discussion is moot anyhow as it is just as much part of the definition
> of a project as the source code.

Agreed. If I7 were up-front about the project being a folder instead
of a single entity, the materials folder could simply be placed inside
the project folder, like Visual Studio's "Resources" folder.

vw