From c2832e4b5de7056485aadf911046467deb7571d6 Mon Sep 17 00:00:00 2001 From: Robert Greene Date: Sun, 2 Mar 2003 23:12:39 +0000 Subject: [PATCH] Juggled FUTURE list a bit and added 1.2.2 completed list. --- TODO | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/TODO b/TODO index 0a9fee3..b22ff31 100644 --- a/TODO +++ b/TODO @@ -2,36 +2,43 @@ THINGS TO DO ============ This is the internal list of items that need to be done. +--- 1.2.2 --- +* ProDOS disks now re-use deleted file entries. Prior to this fix, + deleted entries were never re-used. If importing many files, a + "Disk Full" error would be generated rather quickly. +* ProDOS file entries do not generate spurious file entries. There + was no method of detecting unused entries in pre-1.2.2 code. +* Import file specification should only allow address editing if the filetype + requires it. +* Fixed parsing of filetype definitions for ProDOS volumes. ---- FUTURE --- +--- FUTURE 1.2.x --- o Need to be able to import into a directory in ProDOS. This will most likely involve adding an interface indicating a (writable) directory. This interface would be applied to both disks as well as file entries, if appropriate. -o Import file specification should only allow address editing if the filetype - requires it. o Save does not allow the disk image location to be chosen for new images. (Maybe the wizard should pay more attention?) o Work on identifying why GCJ introduces slow performance to some areas. o Add RDOS writing capability. o Add Apple Pascal writing capability. o HDV disks are not always created to their full capacity. AppleCommander, however, - assumes that the size of the disk on disk is the size of the disk. (Really!) + assumes that the size of the file on disk is the size of the disk. (Really!) This is likely an issue because the ProDOS bitmap indicates there is a certain amount of space and AppleCommander just assumes that the data exists. -o Allow group assignments in import. Not really applicable now that datatype is - chosen by file extension. +o Compile into native executable (hopefully Linux and Windows). +o Short-cut keys would be nice. + +--- FUTURE 1.3.x (or later) --- +o Add drag-and-drop capability. o Provide a Swing GUI so people are not "limited" to SWT. This may be tossed. o Provide a command-line interface (scripting - ie, mass load). -o Add drag-and-drop capability. -o Compile into native executable (hopefully Linux and Windows). -o Sector/Block editor. o Change disk format. -o Short-cut keys would be nice. +o Sector/Block editor. o Open zip files; be able to browse disk images from the zip file. This should be a different type of window (Archive Window?) that allows disk images to be opened into a Disk Window. (Saves would have to be to the file system.) o Open SHK files? Similar operation to zip files. o Open SDK files? Opens directly into a Disk Window. o Make formatted images bootable. May need user to supply a "master" disk from - which files or data is copied. \ No newline at end of file + which files or data is copied.