openMSX
Blendsplitter
This is the new blendsplitter layout for the debugger. Code is usable but still needs some extra love, feedback is welcome.
Things that still need to be implemented
- Better cursor shapes when splitting
- Saving/loading of the session layout of all work spaces, splitters and states of switchingwidgets
- Splashscreen at startup with tips to explain the new way of working.
- Maybe drag-and-drop to switch switchingWidgets from place in the splitters
- Icons in the drop down so that the combobox is smaller and text only show when selecting
Looks good with blendsplitter! I tried this version today but it seems the codeview is not jumping to the position of PC, it is always at #0000 for me. Am I missing something here? Stepping over code F8 also does not change the code view.
It also takes some time on my recent laptop to start the debugger (around 7 seconds) until the gui shows. The non-blendsplitter version is instant (for instance build 126).
Looks good with blendsplitter! I tried this version today but it seems the codeview is not jumping to the position of PC, it is always at #0000 for me. Am I missing something here? Stepping over code F8 also does not change the code view.
That is more because I missed something, more precisely I must have missed a signal/slot connection somewhere.
Allow me to quickly explain: The old debugger had exactly one code viewer, one register viewer, one stack viewer, one main memory viewer etc. You could hide them, but there was always one instance of them in memory. And the code used that knowledge. So the code viewer held the 64 KB the cpu could see, the register viewer was responsible for updating registers and telling the code viewer that PC had changed and the stack viewer that SP had changed, the slot view told the code viewer if the visible memory had changed etc. So there was a lot of signals-slot connections between these single instances of the widgets and the debugger depended on those signals to work.
In the blendsplitter way of working you can of zero, one or even more of every possible widget. So the new class SignalDispatcher is now kind of a data bus that is responsible for all those signals and data centralization. It is clear that I somewhere missed hooking up a few signals and slots when I was trying to understand the spaghetti of signals that was being thrown around. I have not yet done an actual debugging session myself with the new code, being solely focused on getting all widgets to show up properly and having the data sharing working reasonably well.
It also takes some time on my recent laptop to start the debugger (around 7 seconds) until the gui shows. The non-blendsplitter version is instant (for instance build 126).
I'll have to look into that. There is a lot of extra internal overhead now before the GUI can be build but going from 0 to 7 seconds seems like a lot of overhead. On the other hand: your screenshot suggest that you use the default workspaces, so I would suggest closing the other workspaces and saving a single (cpu) workspace as your default startup (there is a new tab under System -> Preferences..). At the moment you are also instantiating the sprite viewer, the tile viewer, the bitmap viewer and all the vdp register viewers. So in effect the debugger has to do a lot more work in comparison with the old debugger, so if you could try that first...
Thanks for your extensive explanation about the connections and codeview not following PC. The non blendsplitter debugger also has problems syncing the memory mapper pages with the emulator.
Because of this PC following "bug" I cannot switch to this build right now, since I need it to debug code.
I have limited the debugger to a single workspace, this indeed makes the startup quicker. This also want me to have just a "save workspace" next to the "save workspace as" option.
Just tried build #131. Is this fixable? Stepping though the code first centers something, then puts it where it should be.
https://user-images.githubusercontent.com/78371947/167933300-74d287b2-6002-4245-8a89-55ff950a0cf7.mp4
Sorry, never mind. I sow that you already saw this issue yourself.
Also the memory layout is always wrong (at least the memory mapper segment). This was also the case in the non-blendsplitter version, so not really related to this version.