Step back not synced with the GUI

[Colpocorto]

Environment:

-OpenMSX 19.1
-Windows 10
-Debugger version 0.10.0-541-geb4d120

Steps to reproduce this issue:

-Open an OpenMSX session and the Debugger
-Break the execution (with console command debug break, the GUI button or adding a break point).
-Step back with console command step_back.

The GUI does not seem to be aware of the step back and remains unchanged.

Furthermore, using F12 to step back on the GUI is sometimes extremely slow (about 2 seconds each step back) and that's why I started using the step_back command.

[m9710797]

Thanks for this bug report. Though it's unlikely it'll get fixed: we more or less stopped development on the (external) openMSX debugger.

In the latest openMSX developer snapshot we have integrated a debugger directly in openMSX itself. New development is (mostly) only done in that debugger.

Part of the motivation for this change is exactly bugs like this one. The old debugger was indeed hard to always keep in sync with the openMSX state. The new debugger is always in sync because the state is not duplicated between two applications. Also the communication with the debugger is much faster now: all debugger views are always real-time updated.

So again, thanks for your bug report, but please try the new debugger in the latest openMSX snapshot.
It's still work in progress, but most things already work nicely, often already better than in the old debugger.
And of course any feedback on the new debugger would be highly appreciated.

[Colpocorto]

Thank you for your response. Having an integrated UI for the debugger makes sense absolutely. Anyway, I just hope the emulator will still be accessible remotely. Having extermnal control capabilities is a basic feature for me (I usually integrate the virtual MSX into my tool chain and other scripts).

[MBilderbeek]

Yes, that's not changed. We're hoping for your feedback! Do you know where to get the latest development build? See also https://www.msx.org/forum/msx-talk/openmsx/please-help-testing-upcoming-openmsx-release?page=69

[Colpocorto]

Hi, thank you for the hint.
I have tried the new debugger and to be honest I do not like it at all. I understand that it is still in development and tons of things will change and will be improved. The classic Borland-like hotkeys for debugging (F7, F8, F9, etc.) do not seem to work. Maybe it is a matter of configuration?

Also, having everything as floating windows without an "always-on-top" feature is terrible. Also I would prefer having all of them as dockable windows so I can move them all together to a different monitor.

As I said before, I understand this is a WIP development and I should wait for its final form. I'm pretty sure you will do an excellent job. But, currently, I don't like it.

[m9710797]

Hi Colpocorto,

You wrote: "...I understand this is a WIP development and I should wait for its final form ...". But without feedback like this, things won't get fixed. So thanks a lot for this feedback!

Now more specifically about the two items you reported:

• Keybindings (F7, F8, F9, ...):
  The difficulty is that, for now, we don't have keybindings that can change depending on which window has focus. It's easy to configure this yourself with commands like bind F7 step, bind F8 step_over, etc. Though that will conflict with the regular meaning of F7, F8 in openMSX (by default it are the SELECT and STOP MSX keys). I think for beginner openMSX users it's better to keep the current meaning of the keys. More advanced users (those that need the debugger) can then customize their own bindings. But for sure we need to document this better (ATM there is no documentation at all on the new openMSX GUI/debugger yet). In the future we may create window-specific keybindings, but possibly not yet in the first release.

• Many separate floating windows: actually all (floating) windows are dockable, try dragging a window near the inside border of another window. Here's an example of a debugger layout I created. Next to docking the windows I've also hidden the title bars (when docked click the triangle in the title bar). This larger window can then be moved as one window. Other people prefer to undock the main openMSX menubar (via the triangle on the left) and then use that window as the root to dock their other windows. This also still needs documentation.

Please try and let us know if these solutions/workarounds work acceptable for you. Any other feedback is also very welcome.

Thanks.

Wouter

BTW: maybe this thread in the openMSX-debugger project is not the best place to discuss openMSX issues itself ;-)

[Colpocorto]

Ok, I will create a new issue on the main OpenMSX repository to address these features.

To be back on topic, I have checked that one of the issues I reported at the beginning of this thread (the extreme slowness when stepping back with F12) has been solved using the old debugger UI with this new OpenMSX build.

That suggests that the issue wasn't on the UI side after all ;-)