I used to use ShapeShifter on my Amiga 3000 back in the day so am familiar with the work of Christian Bauer, very talented.

I just started emulating vintage Macs on OS X/macOS recently with Basilisk II and SheepShaver, and so far so good, colour being the biggest change since my black and white 68030 native A3000.

One of the frustrations I had with Basilisk II is the non native GUI for OS X. It doesn't always let you click the button and I can't say I'm a fan of X11 interfaces on Macs.

As such about a week or so ago I started writing a new GUI following along the lines of the existing GUI in Xcode Swift. I've just finished the first beta version and was wondering if anyone wanted to test it?

My aim is to include the possibility of presets in the interface so that you don't have to reconfigure it each time to use System 7 or Mac OS 8 or different CPUs, RAM, ROM etc.

At the moment it simply does the same as the X11 GUI.

If anyone is interesting in testing it, please let me know and I'll upload a beta. I haven't had much time to test it myself but it seems to work. And unfortunately I won't have much time to work on it in the next week. It's written from the ground up in Cocoa/Swift. Not sure how backwards compatible it is with earlier versions of OS X, it's written in Xcode 10 for High Sierra, but have not locked it to that OS.

Since I've already spent years fine tuning presets for each OS version for my single runtime shells, I'm not likely to use an external GUI, but if you need any help with appropriate presets, let me know. There's a few things like needing the extra file sharing extension for 7.1 in order to use the shared folder that would be nice to put as tips in the GUI as well (so if you select 7.1 as your target, you get some extra instructions on in-OS configuration that may be needed if you select a shared folder).

Yeah I'm aware of a few issues. Sometimes the textfields won't display the prefs contents after a reload, but that seems to be hit and miss.

Main issues I've noticed is I haven't yet converted a new user entry into RAM size back into bytes and haven't implemented the FPU option. Also choosing Maximum for window size returns 0 when you reload. Will fix all these when I have more time.

Here are some first experiences with your GUI application.I tested it in High Sierra, I put your GUI in the folder where the BasiliskII application and the old GUI reside, and I started with copying my existing ~/.basilisk_ii_prefs to ~/.basilisk_ii_prefs_test.

1. Closing the window does not quit the applicationI am used to dismiss such one-window applications by clicking the red button. Most such applications will then quit. Your GUI app continues running when its window is closed with no way to bring the window back.

2. Lines in the prefs file are duplicatedSaving a change in the GUI should only change the related line in the prefs file or replace the content with the new settings, but often lines are duplicated or even all lines are duplicated as if the new settings are appended to the existing ones. After only a few changes in the settings my prefs file had grown and looked like this: http://ronaldpr.home.xs4all.nl/basilisk ... ntries.txt

3. Volumes list, Finder iconsI am not sure why you use Finder icons before each volume in the list, regardless what kind of volume it is. It seems to indicate a compatible startup volume, but it is used for any volume.

4. Volumes list, "Kind"There is a column "Kind" that indicates that the volume is a disk image. Isn't that superfluous information? Aren't all volumes in the list disk images?

5. Volumes list, "Not Found"If a volume is not found, this is displayed in the Kind column. That is useful information, but the further implementation is problematic:

6. Files not found will be removedWhen settings are saved, files that are not found will be removed from prefs.

For me that is a problem. I am in the habit of moving files out of the way in the hosts Finder when I do not need them and move them back when I need them, That way I can choose which disk images will be mounted in BasiliskII without the need to change settings. I do not know if many other users handle disk images with BasiliskII or SheepShaver the same way. Both applications will simply ignore incorrect paths to disk images.

Another problem for me is that I often use relative paths (file names only) for files that are in the same folder as the BasiliskII application. Those will also be removed when I save changed settings. The old GUI does not change such entries.

7. Incorrect removal of not found disk imagesWhen not found disk images are removed from the prefs file, only the path is removed. The "disk" entry remains, causing persistent "Not Found" volumes in the list. The whole line should be removed.

8. Incorrect reading and writing of values for CPU type and FPU.I have not extensively tested this, but I seem to be unable to set all combinations correctly.

These five settings in the GUICPU 68020CPU 68020 with FPUCPU 68030CPU 68030 with FPUCPU 69040

should we written in prefs as:

cpu 2fpu false

cpu 2fpu true

cpu 3fpu false

cpu 3fpu true

cpu 4fpu true

9. Does not create a prefs file when none existsWhen launched, the GUI app should create a prefs file when none exists. It could be an empty file, but it could also be a file with some default settings. More recent (2011) versions of the old GUI create this file with some preconfigured settings: http://ronaldpr.home.xs4all.nl/basilisk ... refs_1.txt

Personally I would choose other values to be the default for some of these settings but that can be discussed later.

If these settings are copied to ~/.basilisk_ii_prefs, your GUI app will crash at launch. Not sure which lines cause the problem. Maybe it is because items are in a different order.

- Now quits when the window is closed- I did not see duplicated lines anymore- Values of CPU type and FPU are now written and read correctly- When no prefs file exists, it will create one(However, if saved without changing anything, the resulting prefs file will cause the application to crash.)

Remaining issues:

1. The app crashed on several prefs files I threw at it.I think that the way it reads the prefs file is fundamentally wrong. Like the old GUI and like BasiliskII itself, it should read the existing settings regardless whether those settings are complete or in which order they are listed. People may have a prefs file that is written by a different application or that is configured manually.When saving the settings, it can then write te settings back in its own order.

2. If the prefs file contains paths to disk image files that do not exist in that location, that path does not appear in the volumes list and subsequent saving removes the path from the prefs file. The indication "Not found" is useful, but the app should show the path as it is and not remove it without user intervention.

3. A saved path to the Unix Root (extfs) is not read by the app and subsequent saving removes the path from the prefs file.

4. Does not read back all values for refresh rate (frameskip) correctly

5. I can only change RAM sizes choosing from the menu, not when I enter a value manually.

When this excellent project is done, or even before then, would you be willing to post the source code on GitHub? I've built a copy of BasiliskII that uses a visible file for the prefs (~/BasiliskPrefs.txt), instead of the standard invisible file, and I've patched a copy of the old BasiliskIIGUI to use that visible file. It would be nice to be able to modify your source code so that I could use the same visible file. Thank you for working on this, whatever you decide to do with the source.