Show the drives a file can be dropped on

[ivanizag]

A file dropped on the window went to drive 1 or drive 2 depending on the half it landed on. There was no way to know beforehand which drive was which or what each one had inserted, and no sign afterwards of where the file went. The machines with two Disk II cards have four removable media drives and only the first two could be reached.

What it does now

F8 shows a screen with one area per removable media drive, each with the name of its drive and the image it has inserted, or EMPTY, and the area that would get the file marked with a rule above and below. The same screen appears for a moment after a drop, with the drive that got the file marked, so there is always feedback even without pressing F8.

It is a text screen of 80 columns rendered the same way the help is, so SnapshotMessageGenerator takes the number of columns now.

                             DROP A FILE ON A DRIVE

                    |                   |                   |
                    | ================= |                   |
                    |                   |                   |
        S5D1        |       S5D2        |       S6D1        |       S6D2
                    |                   |                   |
     dos33.dsk      |       EMPTY       |  Apple II Pascal  |  choplifter.woz
                    |                   |    1.3 APPLE0_    |
                    |                   |  680-0282-A.dsk   |
                    | ================= |                   |
                    |                   |                   |

            The file goes to the drive of the area it is dropped on

The drives

They register with a label and tell the media they have, so the frontends ask the machine with GetRemovableMediaDrives instead of assuming two: a machine with two Disk II cards shows its four drives and a file can be dropped on any of them. The name of the media is written by the emulation goroutine and read by the frontends, hence the atomic access.

frontend/shared

A new package for what the frontends have in common and the emulator library has no place for: the composition of the screen, on a small text canvas, and the mapping from a position on the window to a drive.

Per frontend

• a2sdl reads the position of the pointer on the desktop when the file is dropped. The mouse motion events do not arrive while another application drags a file, so the last known position was stale and the file could land on the wrong drive. SDL2 does not report a file being dragged over the window at all, which is why the areas are shown with F8 and after the drop.
• a2sdl3 shows the areas while the file is being dragged over the window, with the one under the pointer marked. Only SDL3 reports the drag.
• a2ebiten had no drag and drop at all, although the help it shows said otherwise. Ebitengine hides the paths of the files dropped, but it opens the real files and the handle tells the path back, so the images load like on every other frontend, compressed files included. It reports neither the drop position nor the pointer during a drag, so the area used is the one the pointer was last seen on.

Tests

Unit tests in frontend/shared for the position to drive mapping, the word wrapping of the names and a check that the screen built never exceeds 80x24, for one to four drives and every selection. The help texts of the three frontends were verified to stay within 40 columns and 24 lines.