Cleaner Disk Selection GUI in User mode
Closed this issue · 7 comments
The disk selection GUI feels clunky and takes up some screen real estate.
Possibly use icons and remove the explicit disk image name label from the interface. Fix the combo box so
its a bit cleaner (possibly requiring a simple, custom combo box / dropdown implementation.)
Linking #90 . The import flow is a bit difficult to understand for new users. It may be better to just have a single point of entry for importing disks (which would go hand-in-hand with drag-and-drop support.)
Linking #90 . The import flow is a bit difficult to understand for new users. It may be better to just have a single point of entry for importing disks (which would go hand-in-hand with drag-and-drop support.)
Yes. Change to icon and single click to select the disk image with drag-and-drop support. I think the UI for selecting disk images in Virtual ][ is more easy to understand and use.
Linking #90 . The import flow is a bit difficult to understand for new users. It may be better to just have a single point of entry for importing disks (which would go hand-in-hand with drag-and-drop support.)
I do NOT understand the purpose to "import" the disk image. In AppleWin and Virtual ][, there is no need to import a disk image at all. User simply drag-n-drop the disk image file (.dsk, .po, .woz) into the Floppy Drive or Hard Drive icon and then boot the emulator may do. There is no need to perform any "import" disk operation.
@wyatt-wong You've convinced me. I'll put off another release until this Disk interface incorporates the following:
- No import step
- Ejecting disks saves the image back to its original format; this will take the longest as I need to add "de-nibblisation" routines to convert images back to formats like .dsk, .do, .po, .2mg plus testing to prevent potential data loss
- The user wouldn't need to worry about the "library" folder; it can be used to house the emulator-generated WOZ file as a backup
Drag and drop may come in the following release (0.7) because unlike Virtual ][ and AppleWin, we have multiple media sizes to deal with. For example if a user drags a 5.25" disk into a 3.5" drive, the emulator can respond in multiple ways and each situation would need to be addressed:
- Dragging a disk to an incompatible drive (5.25" disk dragged into a 3.5" drive and vice-versa, or a non HDD image dragged into a HDD slot)
- Drive is not available (another disk is already in the drive)
I'll see about drag-and-drop based on how my first pass turns out.
The "Where in the XXX is Carmen Sandigeo" will trigger a save operation when the player have finished solving a case. So if you implement the "save to the disk image" during eject disk then there is an issue here. I don't normally perform the "eject disk" function at all. The disk save operation should be performed IMMEDIATELY when the game perform the SAVE function.
Writing to the host's disk image would also occur on emulator termination (even if the disk is in the drive.)
There may be some misunderstanding here. When Carmen Sandiego, or any title that supports save and load, reads or writes to its disk, it performs this operation on the emulator's internal representation of the disk. This internal representation is (or is supposed to be) saved to the physical media when the disk is ejected or when the machine powers off (or when the emulator app terminates - same thing.)
It may be possible to mark disks that have been written in memory as "dirty" and then periodically write these "dirty" images back to the physical WOZ/DSK file in the background. This would be a measure to avoid data loss if the emulator crashes or some other fatal issue occurs.
Writing to the host's disk image would also occur on emulator termination (even if the disk is in the drive.)
There may be some misunderstanding here. When Carmen Sandiego, or any title that supports save and load, reads or writes to its disk, it performs this operation on the emulator's internal representation of the disk. This internal representation is (or is supposed to be) saved to the physical media when the disk is ejected or when the machine powers off (or when the emulator app terminates - same thing.)
It may be possible to mark disks that have been written in memory as "dirty" and then periodically write these "dirty" images back to the physical WOZ/DSK file in the background. This would be a measure to avoid data loss if the emulator crashes or some other fatal issue occurs.
I will let you find out how to save the changes back to disk images.
But according to what you said the "periodically" save would NOT be an option in my view. As I mentioned earlier the save should be IMMEDIATELY. It is just like when you withdraw money from your bank account, the amount should be deducted IMMEDIATELY instead of after a periodic time have passed.