#276 Projects mirror file system
I'd like to redifine and reimplement projects to match the following
description. It contains what might be considered a number of
different features, but I think they ought to be treated together, with
an overriding idea of how they all tie together.
A "project" gives the user a view of the file hierarchy, relative to the
project file. It allows users to browse the file system, perform file
operations, and easily run Java-related operations on groups of files.
Creating a project: The user selects a folder from a file selector. The
contents of that folder appear in the tree file view. A few files are
hidden (grayed-out, perhaps) based on the user's default preferences
(such as class files, Language Levels products, a build directory, etc.)
Hidden files are sorted at the bottom of the tree, and a setting allows
them to be completely invisible.
Adding to a project: The user clicks on "New". A new, empty file is
created (but not saved) at the root of the project file system (or, if a
folder or file is selected, inside that folder or next to that file). The
user may edit, rename, and move it just like any other file.
Editing a file: The user clicks on the file. It is opened in the definitions
pane if it is in a format that DrJava understands. Java files use Java
syntax highlighting; other text files use a basic text editor. Hidden
files cannot be edited [that's open to debate].
Browsing directories: The directory tree can be expanded and collapsed
as usual. All files in the corresponding directories are listed. Hidden
directories cannot be opened [again, open to debate]. Symbolic links,
aliases, etc., can be followed.
Manipulating files: The interface provides facilities to rename, move,
copy, and delete files and directories. Moving is accomplished with
drag-and-drop. Renaming is accomplished by clicking on a selected
filename. (That is, as much as possible, we match the behavior of
Windows Explorer or Apple's Finder).
Compiling: When the user clicks on "Compile [all]", all non-hidden files
recognized by DrJava as source files are compiled. The user can
restrict this search to a subdirectory (or subdirectories) by specifying a
source root for the project (preferably, this is done in and reflected by
the file tree hierarchy -- perhaps source directory icons are colored
differently). If there is a build directory, class files are generated there;
all non-source, non-hidden files under the source root are copied into
the build directory. (The source-root-based search may need special
support for symbolic links to prevent infinite recursion.)
Testing, Javadoc, etc., works analogously to compilation.
Hiding files: The user can choose to specify certain patterns of files to
hide in the project preferences. These settings, by default, are copied
from a DrJava setting. To overide the pattern-matching, specific files
can be individually "blacklisted" or "whitelisted" in the file tree
hierarchy. (In addition to standard pattern matching, a custom
"pattern" matches all *.java files with corresponding Language Levels
sources.)
External files: In addition to the tree hierarchy, the usual list view of
files is maintained for any additional files (outside the project tree) the
user chooses to open. These files are *not* matched by compilation,
etc., since the source root(s) must be at or below the level of the
project file. The same operations allowed by DrJava when no project is
open are allowed here; the same settings (such as classpath for
compilation, etc.) apply [this is open to debate].
Storing projects: The following information about projects is
persistent: classpath (defaults to system pref), source roots (defaults to
project file's directory), hidden file patterns (defaults to system prefs),
the hidden file blacklists and whitelists (which should not contain
extraneous elements, such as a file in the whitelist that is not matched
by any hidden file patterns; empty by default), and the working
directory (defaults to project file's directory). As much as possible,
changes in the file system (such as files that no longer exist) are
accepted silently, and the references in the project file are fixed.
Optionally, scrolling, text selections, external files, etc. can be stored
with the project. All file references in the project file are relative to the
project file's directory, thus allowing complete portability.
Modifications outside DrJava: As much as is permitted by the Java APIs,
file and directory editing, creation, deletion, and renaming that occurs
outside of DrJava is immediately reflected by the browser. This only
needs to involve some sort of notification when changes from within
DrJava conflict from outside changes (e.g., a modified file in DrJava is
deleted by someone else).
******
The general philosophy here is that we keep projects simple but just
making DrJava (when in project mode) a file browser. There's no need
to explicitly specify which files need to be "open" (which, usually, is
*all* of them). There's no need to go elsewhere to perform file
operations (and then deal with all the trouble that causes when DrJava
sees files disappearing). It's obvious when something is excluded, for
example, from a compilation, so there's no potential for confusion
when something ought to compile but it just doesn't work. I think
those ideas gel well with the application's goals of simplicity and ease
of use.
