New Menu Handling

[ChetSimpson]

Over the last few days I've managed to make a fair amount of progress on getting the cartridge interfaces moved along including updating how the cartridge menu is handled. The cartridges no longer need to build the menu when they start up or rebuild the menu any time a property of the cartridge changes. Instead, when the cartridge menu is about to be opened the main application will fetch a list of menu items from the attached cartridge. This changes how the menu id's are handled, before the cartridge had to have knowledge of the id range (5000-5099) now their id's start at 0. This also adds separators in sub menus and by the time the release is complete checkboxes and disabled states.

I wasn't going to replace the menu system (CartridgeMenu is completely gone) but having it done makes separating the UI and device implementations of a cartridge easier. I've also been working on updating the menu to select the cartridge there instead of by file and it the old system kept breaking and getting in my way.

Here's a screenshot that shows the submenu separators along with the list of cartridges to select from.

[ejaquay]

The MPI interface is pretty good the way it is except right now it can't even load a rom cartridge without crashing VCC. My fault for not paying attention. I thought pulling a couple PR's that were just adding doxygen comments would be harmless. I spent a lot of time last summer getting the interface and mpi configuration to work properly and not crash vcc. Now it does not work.

Too many PR's that do not fix listed issues and that are not even being tested properly. There is going to much more scrutiny on PR's and what changes are being made in the future. Sorry for the rant but I am sort of pissed.

The MPI menu shown above might seem easier to use but it is probably not. Visibility and control over what slots cart are in is just as important as what is being loaded. Unless we create a cartridge metadata system (like mame) we will still need to let users select what cart to load by browsing files in a directory and forcing those file to exist in any particular directory is a bit of a non-starter.

[ejaquay]

I found the bug by finding the commit that caused it. After that simple inspection shows code changes in a couple of PRs that claimed to be just be adding comments. My bad for not doing that inspection and rejecting at the time. I am not perfect, specially when I am less than a month from a major surgery. The fact is simple unit testing on your part would have found the bug and should have before the PR was even issued. Nor should a PR be doing things not mentioned in the commit comments.

The following sums up a major problem: "If I make a few or even a fair number of bugs while improving a garbage code base I'm ok with that because I know that at the end of the day the entire program is going to be better off."

We simply can not work that way. There are issues besides "the code is garbage" to fix (There is a list that will be growing as we test and from user experiance) and we can't if you are creating new issues while radically changing the code. To fix the current issues the rest of us have to spend time understanding, agreeing to, and working with the changes you have done and are planning to do and that is not going to happen overnight.

A better process would be to enumerate specific things you see wrong with enough detail that we can consider and then collectively work on them. "Garbage" maybe desciptive but is not nearly specific enough for consideration.

Now to go down the list you supplied.

1. Changing build output locations. I want them the way they are except for a couple of debug builds going to the wrong place and if I decide to fix them I will let everybody know in advance. You are free to write your own private scripts to copy outputs from where they are to where you want.
2. Multiprocessor compiles OKAY.
3. Clean up orch90. Why? "Shitty" code is not a valid reason. Need specifics.
4. Clean up GMC. Why? Is it broken?
5. Clean up Becker. Same
6. Clean up RamDisk. Same
7. Update HardDisk. Works now.
8. Update SuperIDE. Works now.
9. Update SDC. Fixes only. I am aworking on some.
10. Update ACIA. Maybe use libcommon for network
11. Update FD502. Works now.
12. Make cartridges a dependancy of VCC. Need specifics.
13. Remove procedural interface for carts. Why? Rom carts are dumb. Interface is minimal.
14. Fix documentation. OKAY.
15. Move interrupts back into vcc. I would trust Craig to do that after he fixes robocop.
16. Replace menu handling. The long term goal of menu handling changes should be towards cross platform. Changes must be pre-approved with mockups.
17. Move cartridge slot to vcc/bus Why? Again "Shitty" code is not a good reason.
18. Unit tests. OKAY as long as they require no code changes.
19. Formalize device interface. Document first.
20. Common component for DMK disk image. NO. Not common. FD502 only.
21. Refactor FD502 to not use capi. Not now.
22. Refactor HardDisk, SuperIDE, or SDC. Not now.
23. Refactor Becker Port with boost. NO Vcc builds and works without including 3rd party libraries. (legacy exception for opengl but legacy will go away in time)
24. Craft common serial interface. OKAY.
25. Cartridge reset timing. Okay if that addresses a specific issue.
26. Move C string based API's out of libcommon. OKAY if done carefully.
27. Changes to MPI config menu. Subject to preapproval.
28. Fixing to TODOs and FIXME. Okay if they are causing specific issues.

[ejaquay]

Are you saying it's so much harder to choose a cart DLL from an automatically populated menu instead of navigating away from my ROM directory, selecting the DLL, then when I want to insert a ROM navigating back over to my ROM directory to select it.

I have been thinking about adding that problem as an issue. It would be nice if the ROM directory stored in the config was different from the DLL directory. That will require changing the MPI config to allow user to choose which is being loaded while presenting the directory or list. For testing purposes there is still a need to have a directory other than vcc's .exe directory for the DLL's

[ChetSimpson]

I found the bug by finding the commit that caused it. After that simple inspection shows code changes in a couple of PRs that claimed to be just be adding comments. My bad for not doing that inspection and rejecting at the time. I am not perfect, specially when I am less than a month from a major surgery. The fact is simple unit testing on your part would have found the bug and should have before the PR was even issued. Nor should a PR be doing things not mentioned in the commit comments.

Ok, so you want to make a big deal out of something that's not and then continue to nitpick about it. K.

The following sums up a major problem: "If I make a few or even a fair number of bugs while improving a garbage code base I'm ok with that because I know that at the end of the day the entire program is going to be better off."

We simply can not work that way. There are issues besides "the code is garbage" to fix (There is a list that will be growing as we test and from user experiance) and we can't if you are creating new issues while radically changing the code. To fix the current issues the rest of us have to spend time understanding, agreeing to, and working with the changes you have done and are planning to do and that is not going to happen overnight.

I think there's some confusion here. The PR's I've submitted were done as a courtesy to aid in improving your overall codebase. Since you were initially receptive I continued to submit them until you unceremoniously "locked" everything down and only accepted bug fixes. While I have no problems fixing any issues you might find, my focus, priorities, and schedule haven't changed.

A better process would be to enumerate specific things you see wrong with enough detail that we can consider and then collectively work on them. "Garbage" maybe desciptive but is not nearly specific enough for consideration.

The FD502 has several parts to it. The UI, the FD502 logic, the WD1793 logic, the disk drive logic (for index hole timing), and the virtual disk image. The problem is that it's all mixed together - all parts are tightly coupled with at least one other part, there's no cohesion, there are numerous code complexity issues, it leaks memory, has potential buffer overruns, the code is far from testable, and fair amount of just general bad coding practices including these absolutely useless micro-optimizations - if ( (Side==1) & (CurrentDisk==NONE) ). Then there's the code in the FD502 that's duplicated in other cartridges and the details that are leaked everywhere, and JFC the menuing which is ridiculously dumb. Now extrapolate that or whatever to the other cartridges except maybe acia which is ok and you're covered. These problems have nothing to do with the language it was written in, the paradigm that was followed, or when it was written - it's just garbage. I haven't gone over VCC proper in detail yet but I don't expect my opinion to change much if at all when I do. If you don't happen to see those things maybe have a few conversations with Copilot while it reviews the code.

Now to go down the list you supplied.

Again, I think there's some confusion here. I wasn't soliciting your approval for any of changes that I've made or will be making. Just a courtesy heads up so you know what work is going on over on my side and can decide whether you want to tag along. The items that are marked done are all merged into my develop branch. Several small pieces of functionality are disabled or non-working since they're part of code that's about to get nuked so be aware of that if you ever pull anything.

[ejaquay]

I wasn't soliciting your approval for any of changes that I've made or will be making.

I can not guarantee the work you are doing will be accepted as part of VCC. I would like it to be but if you can not accept that is is a team effort that might be difficult.

[ChetSimpson]

Yeah sorry, I'm just not down for doing things in the most ass way possible.

[ChetSimpson]

Cleaned up the menu a bit, added icons to show which drives have disks, added icons to show which slot is selected, re-added the multipak slot submenus, show inserted cartridges as disabled, but still need to add variable levels of sub menus to support the ROM MRU stuff. The other drive controllers will get the same treatment for their mounts and most of what is shown will be configurable and it'll all translate over to the MPI (and other multi-slot carts) just fine. Doh!

[ejaquay]

My thoughts on the above layout

I like the Cartridge Port mouse over dropdown with some added comments/clarifications.

1. "Insert Recently Used ROM again" is not necessary because that should have been stored in the ini file and will be automatically loaded when Vcc starts.
2. The paths of hardware paks are stored in the vcc ini and except for the MPI these are used to populate the "Insert [hardware pak] items". The mpi.dll should always be the vcc execution directory.
3. Maintain hardware pak list item is added that brings up a dialog that allows users to maintain the hardware paks stored in vcc ini via a file chooser.

I do not like moving the Slot selects from the non-modal MPI config dialog. The cartridge select mouse over dropdown as per above can work just as well from the MPI config dialog, the only change to it would be to remove the option to insert mpi.

My plan is to eventually move disk selects to non-modal disk control dialogs as well, the only things on the dynamic menu would be config and/or control items. I was envisioning allowing a user to open a directory containg related .dsk files and having a non-modal "next disk" button to toggle through them for dealing with "insert next disk" prompts like sdc does. I also envisioned a clean seperation beween "config" and "control" callbacks in the pak interface which I think still makes sense.

[ejaquay]

I understand your frustration, but Craig and I are frustrated too because the changes you have made have hindered our ability to address the published issues. Instead, we are being forced to focus on design concerns. I was hoping Craig would be working on the Robocop cart issue (a change he made broke it), but he can’t if rom_cartridge() is still in flux.

You probably realize that in my fork I have modifications to the project build files that allow selectively linking libcommon either dynamically or statically, and I’ve been experimenting with both. Unless there is a groundswell of support from all team members to abandon a static library, I intend to keep that choice available to us.

At this point, static links do not work 100%, and some changes are necessary to make them function properly. I’ve been studying possible fixes—at the very least, logging has to work across boundaries. I hope to publish a VCC programmer’s guide within a reasonable amount of time which, if followed, should make the goal of having a choice possible. With your expertise and experience, much of it will be obvious to you, but it will be new material for at least some of us—it certainly is for me. There has been nothing to suggest that the CartridgeFactory cannot be made to work with a static library.

One very obvious point is that since static libraries cannot contain resources, they would have to be in vcc.rc for static builds. Pretty icons are nice, but unless minds are changed, those resources cannot be in libcommon.vcc. I also don’t like the undoing of my work to move the DLL configuration out of the dynamic menu—I did that for good reasons.

[ChetSimpson]

I understand your frustration, but Craig and I are frustrated too because the changes you have made have hindered our ability to address the published issues. Instead, we are being forced to focus on design concerns. I was hoping Craig would be working on the Robocop cart issue (a change he made broke it), but he can’t if rom_cartridge() is still in flux.

Ridiculous on both counts. I'm not at all frustrated so I'm not sure why you think i would be. The rom_cartridge implementation can't possibly be in flux because the main branch is locked down to only bug fixes. What are you concerned about this time?

I don't care about the rest of it. Choose wisely.

[ejaquay]

I try my best to choose wisely but given my fallibilities that is not always possible.

The only choice made is that libcommon be buildable as either DLL or lib so resources for the screen you propose would go in vcc or mpi. Calling it garbage does not help.

Proposals to change the interfaces users see will always be considered but not guarantee of acceptance.

[ChetSimpson]

the screen you propose would go in vcc or mpi. Calling it garbage does not help.

Create a resource only dll called where-we-put-all-of-our-shared-windows-resources-so-all-cartridges-can-use-them.dll and stop acting like its a problem.

[ejaquay]

Create a resource only dll called where-we-put-all-of-our-shared-windows-resources-so-all-cartridges-can-use-them.dll and stop acting like its a problem.

Not an act. Problem is the cartridges become dependant on them.

[ChetSimpson]

It's new! IT's fresh! It's hot! It's almost there! Yeah BOYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY!

[ejaquay]

Closed. Discussion continued on #520