Extensible format submenu
Martin Bazley (331) 379 posts |
I’m sure this has been suggested before, but anyway… The ‘Format’ submenu, on drive icons, is now completely obsolete. All it offers are a selection of floppy disc formats (unlikely on the Iyonix, impossible on the BeagleBoard), and even more obsolete DOS and Atari formats. This is also an excellent opportunity to make SCSIForm and HForm more user-friendly. How about revamping the submenu in a similar fashion to what Acorn did to Configure a decade ago? Instead of a list of hard-coded defaults, devise an API which allows any given module (or possibly executable) to add itself to the list of formatters known by any given filing system. (The existing formatters, if necessary, could be converted to this new API.) So, for example (I’m not entirely sure what the distinction is at a low level, but I know I have SCSI::4 and ADFS::4), SCSIForm and HForm wouldn’t appear on the same list. The ‘Formatting’ status window could also be made open to external applications (a la Free/Filer Action), if it isn’t already. The application I’m principally thinking of is Fat32Format, as an up-to-date replacement for the obsolete DOS options in the case of removable devices (e.g. USB sticks). While we’re at it, a cut-down version of SCSIForm should probably be included in ROM (and made available on the list) to make BeagleBoard setup less scary. (I’ve seen the BASIC code, and an assembler version should be pretty tiny.) |
Sprow (202) 1155 posts |
You should consult service call &6A (filer enumerate formats) and all your wishes will come true. |
Martin Bazley (331) 379 posts |
That’s not useful when the format submenu is greyed out in the first place, i.e. for every type of device except floppy discs. I also don’t think a single-tasking BASIC program is an appropriate way of formatting a hard disc, especially when it has an entire useless menu begging for the job. The hard-coded defaults of 1.6MB etc. would obviously be worthless, hence the need for different devices to report different possible formats (something else the service won’t do). |
Dave Higton (281) 668 posts |
Surely the point of a single-tasking programme is to ensure that nothing else can even attempt to access the device while it’s being formatted? How would you ensure that in a multi-tasking environment? |
Jess Hampshire (158) 865 posts |
It would be very nice for all the relevant formatting options to be called from that menu. (However it is achieved). It would also be good for a basic formatter to be in ROM. (And ultimately a package manager, so all you need is the rom and a net connection). However, I don’t think it would be a good idea to change the current formatter until we have partition support. Ultimately it would be nice to have something like GParted. (Which would presumably switch to single tasking only when it was applying any changes.) EDIT: But it would be nice to update it. |
Martin Bazley (331) 379 posts |
In exactly the same way as the current floppy formatter ensures it. |
Matthew Phillips (473) 719 posts |
Another irritation is that with the Format menu greyed out you cannot view the current format of the drive, making it harder to work out whether it’s a Filecore format, FAT12, FAT16 etc. |
nemo (145) 2529 posts |
Anyone plumbing HForm into ADFSFiler is taking the whole “you can kill RISC OS with one click” to rather extreme lengths. ;-) There’s an argument for a Windows-like “Properties” dialog, but formatting needs to be buried behind a lot of “are you REALLY sure” stuff. I know it’s RISC OS, but… :-D |