mirror of
https://github.com/AppleCommander/AppleCommander.git
synced 2024-12-22 08:30:35 +00:00
50 lines
2.5 KiB
Plaintext
50 lines
2.5 KiB
Plaintext
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.
|
|
* 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.
|
|
* ProDOS subdirectories need to allocate another block as they fill up; otherwise
|
|
the directory is limited to the number of entries the fit within the allocated
|
|
space.
|
|
|
|
--- FUTURE 1.2.x ---
|
|
o Import could use a progress indicator.
|
|
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 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 Compile into native executable (hopefully Linux and Windows).
|
|
o Short-cut keys would be nice.
|
|
o Need to update preferences with import location, disk creation location.
|
|
|
|
--- 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 Change disk format.
|
|
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.
|