[plt-scheme] saved window configurations

I think projects are usually associated with things like build options
and library constructions, etc etc, so maybe you're rewriting history,
or there are more steps in there.

Robby

On 9/26/07, Anton van Straaten <anton at appsolutions.com> wrote:
> Matthias Felleisen wrote:
> >
> > On Sep 26, 2007, at 10:04 PM, Anton van Straaten wrote:
> >
> >> However, I wasn't actually arguing for doing that (yet!)  Instead,  I
> >> was saying that generalizing the idea of saving a list of open  files
> >> would provide for future extensibility in that direction,  among
> >> others.  Since DrScheme is an extensible environment,  providing
> >> features in a form that can easily be reused by other  extensions
> >> seems appropriate.
> >
> >
> > As Robby pointed out, a product is uniquely determined via its main
> > module. So a useful tool is one that opens all transitive (file ...)
> > dependencies in tabs and/or the module browser.
> >
> > [We did have a notion of a project, unless my memory deceives me. So  we
> > are not speaking w/o experience.]
>
> My suggestion was definitely not about introducing a project
> abstraction, or having a way to transitively open all files associated
> with a program.  It's almost the opposite, in fact: the idea of the
> task-focused approach is that one typically only deals with a subset of
> the files in a program at any one time, and it helps if the development
> environment lets you focus on that subset and nothing else.  However, to
> do that effectively, it helps to have ways of identifying those subsets,
> saving them, and reactivating them at some later time.
>
> In general, these subsets tend to cross-cut the overall program in
> almost arbitrary ways: the connection between the files you're
> interested in at any one time may have to do with the dynamic flow of
> execution, or with data structures that are shared across modules, etc.
>   Practically speaking, today at least, there's no way in general for
> the environment to predict what files you need for a task you want to
> perform.  So the task-focused approach lets you identify a set of files
> you're interested in, save that somehow, and reuse it when you need it.
>
> On the subject of projects, where I was coming from when I mentioned
> recapitulating the history of IDEs is that a common path in IDE
> development seems to have been:
>
> 1. Simple single-file editor.
> 2. Support multiple files open simultaneously.
> 3. Remember the set of open files between invocations.
> 4. Add a project feature so that you can easily switch between sets of
> "known" files.
>
> This thread began with a request for #3.  For the same sorts of reasons
> that I described above, #3 is a reasonable request, even given
> DrScheme's understanding of modules and ability to traverse the module
> graph.  I was just pointing out that providing #3 in a slightly more
> general form makes it quite easy to do:
>
> 5. Support task-focused editing.
>
> That's somewhat orthogonal to whether #4 is provided.  I tend to agree
> that the module browser rather obviates #4, although "projects" are also
> often used to manage non-code resources, which the module graph doesn't
> help with.
>
> Anton
>
>