From: SourceForge.net <no...@so...> - 2006-02-07 00:07:51
|
Feature Requests item #1425713, was opened at 2006-02-06 18:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=1425713&group_id=44253 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Project Facility Group: Large (> 1 pair-month) Status: Open Priority: 5 Submitted By: Dan Smith (dlsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Projects mirror file system Initial Comment: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=1425713&group_id=44253 |