-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve the Configuration GUI #853
Comments
I feel that AppleWin will need to expand its GUI at some point - if it is to keep growing. I don't mind the command-line and all, but there are some, maybe even many, options that need their own buttons and tabs. The RamWorks memory bank options come to mind at the moment. To the right of the ADVANCED tab there looks like there's room for a new ADVANCED-2 tab. Or perhaps 2 or 3 "Aux1", "Aux2", and Aux3 tabs. Perhaps the "Disk" tab could be made a bit smaller to widen the free space. There looks to be 2 or 3 wasted spaces after the "k" in "Disk". I even see some real estate on the "Sound" tab. Don't know what would go there. But it's there. Emulators are technical programs which mimic vintage computers.They have to cover a lot of ground. Especially when they cover expandable systems like the Apple II and Atari 400/800. And this means options. Not only that, but everyone uses emulators in subtly different ways. The more customization offered by the GUI the better. A busy menu isn't a big deal. We like it that there are buttons to play with & tweak. Once you've learned the emulator and need to change something, it becomes second nature. All options are tuned out except the one you're looking for. And us users appreciate an accommodating program, Altirra is a good example. Every release (even the interim beta-tests) get new options. And with today's high-resolution displays and uber-widescreen monitors, there's really no need to cram everything into one menu page smaller than the "Disk Properties" in Windows. |
Make no mistake, we all love AppleWin over here and appreciate the time and effort put into it. Not to mention it's heritage going back some 20+ years already. This and a few other select emulators have support and continuity rivaling and exceeding many commercial products. It's used weekly for all kinds of vintage-ee things. Game-playing, curating/archiving, relaxing with BASIC programming. All sorts of good stuff. |
Thanks for sharing your UI thoughts and also your positive feedback on AppleWin 👍 When we extend & update the UI, I wouldn't want to stick with this out-dated tabbed-property sheet UI, which doesn't scale well for >5 sheets (as you get 2 rows of tabs, with the tabs switching between rows... IMO very confusing!). Instead, perhaps a tree-control on the left, which select a property sheet on the right, eg. like Visual Studio's "Options": Anyway just an idea at this stage. |
I think the VisualStudio style of options looks great and would function well. |
From the 2021 Emulation Evaluation in Juiced.GS here, focussing on AppleWin:
(There is a 2022 update, but it's behind a paywall) |
Yes. Unfortunately there really aren't any good ways to manage lots of options; the UI will always end up cluttered with the user scrolling & searching for options. 3D modeling programs are probably the "best" stress test demonstrating this. A vertical tabbed tree style is "good enough" and solves the immediate needs of providing someplace for users to start customization instead of having to use a clunky [1] command line. As long as we have a search text field and good categories this is probably the best way to go. [1] Clunky for non-power users. |
I cast my vote for the tree-control style GUI. The WinUAE Amiga emulator, which has astronomically more configuration options than any Apple II emulator ever possibly could, uses this type of GUI to great effect, with a smart combination of check boxes, drop-down lists, radio buttons, sliders, etc., with each page consisting of several logical groups of related outlined controls. I also suggest a panel for slot/card configuration that contains a series of drop-down menus, one for each slot. For each slot, there would be a drop-down containing a list of the cards that can go in that slot, as well as an "Empty" option. I think there is too much inconsistency and clutter with the slot options spread out across different tabs. The set of drop-downs could look like the following: Slot 0: Empty Slot 1: Empty Slot 2: Empty Slot 3: Empty Slot 4: Empty Slot 5: Empty Slot 6: Empty Slot 7: Empty Of course, some logic would need to be there to prevent inserting the same card into multiple slots where it doesn't make sense (such as CP/M SoftCard in both slots 4 and 5.) And possibly any configurable options pertaining to a particular card could appear upon selection in a panel to the right of the card selector. The agat Apple II emulator for Windows implements a slot configuration system along these lines already, if you want to see an example. And the Virtual ][ emulator for macOS also handles slot configuration quite elegantly and attractively this way. This would have the added benefit of not requiring the command line to remove certain cards (Disk ][, SSC, etc.) from the configuration. |
This is a pretty broad topic that's come up many times before.
In general we don't have any more real-estate to squeeze more config options in the existing Configuration GUI (aka property sheet pages), so this results in overloaded UI (eg. #852) or configuration only being available from the command line (eg. #712) and so affects discoverability too.
Also a simple interface for selecting cards in the 8 slots would fall under this topic too.
The text was updated successfully, but these errors were encountered: