Comments on the built-in debugger UI

[Colpocorto]

Hi,

I've opened this issue to continue the discussion previously held on this issue from the Debugger repository:

openMSX/debugger#190

Let me quote the last Wouter's response:

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.

Thank you for your comments. I didn't notice that the windows are dockable. I've tried it out and works flawlessly!! Thank you very much, I love it. Once I understand how it works, I admit you have been made a huge improvement here. Congrats!

About the keybindings... this is still an unsolved issue. Having to share the keybindings between the debugger and the emulator itself makes difficult to assign specific MSX keys when using a small keyboard (e.g. a laptop or a bluetooth portable keyboard) with a reduced number of keys.

Are you sure guys the framework you're using for the new UI doesn't allow assigning priority to the keybindings (or just making them active/inactive when getting/losing the focus of each window)?

Other thoughts about the new UI:

-I find the separate console window much less convenient than the former one. Having the transparent console bound to the emulator Windows was ideal (especially when using the "type" command to enter text in a more comfortably way). I would love a configuration option to allow the classic behaviour.

-I see that the value of registers are refreshed in real-time now (not only at break time). How does this impact the performance of the Emulator? Can this behaviour be disabled? Sometimes it was very useful to me to watch the last register values even if the emulation continues running (e.g. I can copy them to my notes while the emulation is running waiting for the next event to break the execution).

-Definitely, an option to make the debugger "always-on-top" would be a dream, especially when using a laptop without a secondary screen. I understand the classic UI hadn't this feature either, but I always missed it.

And this is it so far. Thank you for your efforts and congrats for the new UI. Still some things must be ironed out but I'm confident we've getting a new winning horse here.

[m9710797]

Thank you for your comments. I didn't notice that the windows are dockable. I've tried it out and works flawlessly!! Thank you very much, I love it. Once I understand how it works, I admit you have been made a huge improvement here. Congrats!

Ok, great. But it does show we'll have to properly document it. Apparently it isn't obvious.

About the keybindings... this is still an unsolved issue. Having to share the keybindings between the debugger and the emulator itself makes difficult to assign specific MSX keys when using a small keyboard (e.g. a laptop or a bluetooth portable keyboard) with a reduced number of keys.

Are you sure guys the framework you're using for the new UI doesn't allow assigning priority to the keybindings (or just making them active/inactive when getting/losing the focus of each window)?

We're using Dear ImGui as our GUI framework. At the moment it doesn't have good support for per-window shortcuts (but it's being worked on). Depending on how quickly that feature becomes available and how well it works, we'll either use that builtin feature, or we'll have to come up with something ourselves. It's also not the most urgent thing (as in: other things are more urgent) because there is a reasonable workaround.

-I find the separate console window much less convenient than the former one. Having the transparent console bound to the emulator Windows was ideal (especially when using the "type" command to enter text in a more comfortably way). I would love a configuration option to allow the classic behaviour.

Can you give more details on this item? Because when you place the new console (any window) fully inside the main openMSX window, then it does move along with the main window. And it is drawn partially transparent. (And you can size and place it similar as the old console). (By default) pressing F10 still opens/closes the new console the same as the old one. I'd love to hear in more detail which aspects make it less usable compared to the old console.

-I see that the value of registers are refreshed in real-time now (not only at break time). How does this impact the performance of the Emulator? Can this behaviour be disabled? Sometimes it was very useful to me to watch the last register values even if the emulation continues running (e.g. I can copy them to my notes while the emulation is running waiting for the next event to break the execution).

The "Dear ImGui" framework uses the "Immediate Mode GUI paradigm" (hence the name IM GUI). In this paradigm there is NO duplicated state between the application and the GUI. In this case that means there's NO copy/snapshot of the register values that's shown in the GUI. Instead the GUI just always shows the current values. This paradigm greatly simplifies the code, and reduces the possibility for bugs (no state that can get accidentally out-of-sync, no need for event-handlers or callbacks to sync the state, ...). And there's no performance overhead. Actually making a snapshot and keeping it up-to-date would introduce complexity and overhead.

So if you want to stop register updates, you'll just have to pause the emulation (and then maybe fast-forward after unpausing). I believe that for the majority of the users/use-cases having real-time updated views is more useful than viewing snapshots (I mean while the emulation is also running). Especially for e.g. the bitmap/tile/sprite-viewer, but also for the register view (e.g. watch a delay-loop count down in real-time, or see at a glance how the SP varies during typical execution).

-Definitely, an option to make the debugger "always-on-top" would be a dream, especially when using a laptop without a secondary screen. I understand the classic UI hadn't this feature either, but I always missed it.

I admit I haven't actually tried for the floating openMSX windows. But in my desktop environment (KDE) I can make any window "always-on-top" (e.g. right click the window in the task bar, then select "always-on-top" (depending on the version it might be in a sub-menu). IceWM has similar functionality. And I guess most other window managers have similar functionality?

That being said. There probably are still a few places where a sub-window is not (initially) placed on top of it's parent window. I recently fixed a bug like this, but I also need to audit the rest of the code.

And this is it so far. Thank you for your efforts and congrats for the new UI. Still some things must be ironed out but I'm confident we've getting a new winning horse here.

I agree. But that's only possible with lots of user feedback. It already works pretty well for my personal use cases, but other people have different use cases. So thanks again for your comments.

[Colpocorto]

It's also not the most urgent thing (as in: other things are more urgent) because there is a reasonable workaround.

Well... when debugging, I use intensively keys F4, F7, F8, F9, F11 and F12. Even if I accepted a different set of keys (after all I do on my daily job), there aren't many free keys left to assign all of them. Most available keys have already a different (and needed) function. And using the mouse to click on step into/over/out/back is absolutely a deal breaker for me.

Can you give more details on this item? Because when you place the new console (any window) fully inside the main openMSX window, then it does move along with the main window. And it is drawn partially transparent. (And you can size and place it similar as the old console). (By default) pressing F10 still opens/closes the new console the same as the old one. I'd love to hear in more detail which aspects make it less usable compared to the old console.

Well, this is a bit embarrassing. Again, I didn't notice the console is dockable. I tried to do it wrongly (didn't notice the icon that appears indicating the dockable areas). Sorry for this.
However, I do still prefer it to be transparent. Is transparency configurable?

The "Dear ImGui" framework uses the "Immediate Mode GUI paradigm" (hence the name IM GUI). In this paradigm there is NO duplicated state between the application and the GUI. In this case that means there's NO copy/snapshot of the register values that's shown in the GUI. Instead the GUI just always shows the current values. This paradigm greatly simplifies the code, and reduces the possibility for bugs (no state that can get accidentally out-of-sync, no need for event-handlers or callbacks to sync the state, ...). And there's no performance overhead. Actually making a snapshot and keeping it up-to-date would introduce complexity and overhead.

Understood. Not my personal choice, but I can live with it. I also understand why it's a valuable feature for others.

I admit I haven't actually tried for the floating openMSX windows. But in my desktop environment (KDE) I can make any window "always-on-top" (e.g. right click the window in the task bar, then select "always-on-top" (depending on the version it might be in a sub-menu). IceWM has similar functionality. And I guess most other window managers have similar functionality?

As far as I know, not on Windows. And, although the Linux user base is slowly growing, the majority of users have Windows computers nowadays.

I do think that such functionality would be great but it shouldn't rely on the operating system, since Windows and MacOS can't do it natively (I mean, you can of course design always-on-top forms on Windows and Mac, but the behaviour is controlled by the application and can't be forced by the final user).

I agree. But that's only possible with lots of user feedback. It already works pretty well for my personal use cases, but other people have different use cases. So thanks again for your comments.

Yup. I too believe our feedback is very important (after all, we the users will use the application). I see that virtually no one else has reported any comments about the new UI (but I guess they will once it's included in the next release).

[m9710797]

Hi, just a quick reply (don't have much time right now).

Well, this is a bit embarrassing. Again, I didn't notice the console is dockable. I tried to do it wrongly (didn't notice the icon that appears indicating the dockable areas). Sorry for this. However, I do still prefer it to be transparent. Is transparency configurable?

Did you maybe also miss that it already is transparent? Though only when the console is fully inside the main openMSX window (but that's also the case for the old console). Or do you mean that it's not transparent enough?

The transparency is configurable. Though it's not immediately something we planned to expose. If you want to experiment with it anyway, you can try: Settings > Advanced > ImGui Demo Window (all the way at the bottom). There select Tools > Style Editor. Then select the "Colors" tab, then the 3rd entry "WindowBg", click the colored square, and in the color selector move the transparency slider down (=increase transparency). But again, we didn't plan to expose these very low level settings. Also the default ImGui transparency may be a little more opaque than the old openMSX console, but not too much I think (or it might depend on which background image you used in the old console?)

As far as I know, not on Windows. And, although the Linux user base is slowly growing, the majority of users have Windows computers nowadays ...
I do think that such functionality would be great but it shouldn't rely on the operating system, since Windows and MacOS can't do it natively (I mean, you can of course design always-on-top forms on Windows and Mac, but the behaviour is controlled by the application and can't be forced by the final user).

Those numbers are not really relevant, and it's anyway not representative for openMSX users. In any case, for openMSX development, we get more help from non-windows users. So thanks again for your feedback from a windows-user point of view.

I did a quick google search, and apparently it's also easy to do in windows: via the Microsoft PowerToys utility, and the shortcut Windows+Ctrl+T.

I agree it would be nice if this were configurable in openMSX itself. But since there is an easy workaround it's not high priority at the moment.

[Colpocorto]

Hi, just a quick reply (don't have much time right now).

Well, this is a bit embarrassing. Again, I didn't notice the console is dockable. I tried to do it wrongly (didn't notice the icon that appears indicating the dockable areas). Sorry for this. However, I do still prefer it to be transparent. Is transparency configurable?

Did you maybe also miss that it already is transparent? Though only when the console is fully inside the main openMSX window (but that's also the case for the old console). Or do you mean that it's not transparent enough?

Oh yeah... it seems it's transparent indeed but I didn't notice it because its way darker than the original one. So, if I understood correctly, the "ImGui Demo Window" is more than just a demo, and it can be used to adjust UI parameters actually? I totally missed that.
But again, you solved my concerns:

Thank you!

The transparency is configurable. Though it's not immediately something we planned to expose. If you

It's perfect the way it is exposed currently. Just rename the settings to something else than "ImGui Demo" since that name is a bit misleading.

Those numbers are not really relevant, and it's anyway not representative for openMSX users. In any case, for openMSX development, we get more help from non-windows users. So thanks again for your feedback from a windows-user point of view.

I'm actually more of a Mac user, but I frequently use OpenMSX on the laptop provided by the company I work for (and, sadly, they only allow Windoze computers).

Anyway, trust me on this: Windows users are the majority.

I did a quick google search, and apparently it's also easy to do in windows: via the Microsoft PowerToys utility, and the shortcut Windows+Ctrl+T.

I agree it would be nice if this were configurable in openMSX itself. But since there is an easy workaround it's not high priority at the moment.

Fair enough. It shouldn't be a definitive solution, but it's ok not to make it high priority at this moment.

Again, thank you for your help. The better I know the new UI, the more I like it.

[Colpocorto]

Some other thoughts:

• Sometimes it happens that when a new UI dockable Window is opened, it is shown off the screen and I haven't been able to bring it to the visible area. This is especially frequent when a laptop had a secondary screen connected during the previous session. It also happens if you connect to the box remotely (i.e. VNC or RDP) and the screen resolution is different to the one used during the last session.

• If you have multiple instances of OpenMSX and open the debugger for all of them, it's hard to tell which debugger window belongs to which OpenMSX instance since the title is common to all of them. Maybe there is some way to decorate the Window with the OpenMSX instance ID or name, but I've been able to find it.

• Still, the lack of proper key bindings for the debugger UI is a big problem. Most of the time I use a laptop with a small keyboard and haven't many keys left to waste for this. A priority-based or focus-based set of keybindings is definitely necessary here.

Thank you.

[m9710797]

Hi Colpocorto,

All valid feedback. I'm only afraid that short-term there's not much we can do about this :(

Here's some feedback on the individual points:

• Off-screen windows. That's a general problem, not specific to openMSX. There are various solutions to deal with off-screen windows. We could deal with this is openMSX itself (actually that would require changing the GUI toolkit itself, that's not directly under our control), but I'm not sure that would be a good idea: e.g. if you only temporarily (perhaps even by accident) disconnect your 2nd monitor, you might not like that all windows then automatically move to the primary monitor.
  And I haven't tried, but maybe CTRL+TAB can help you find back missing windows???

• There's no option to decorate all window titles. But this would also have been a problem with the old debugger. So it's not a regression (at the moment the focus is on fixing regressions). And many (most?) other applications that have floating windows also don't have such an option. I don't know if this is worth solving in openMSX. If you keep your debugger windows docked it shouldn't be too hard to keep them apart.

• Key binding issue. Was already discussed before. Still same status.

Ah, did you notice the new options "Settings > GUI > Save layout" and "Restore layout". At the moment these are still experimental. But it could be a partial solution or a workaround for the first two problems.

Thanks for your feedback! Keep it coming.

[Colpocorto]

All valid feedback. I'm only afraid that short-term there's not much we can do about this :(

I understand this new UI is a big development and changing things will take time.

• Off-screen windows. That's a general problem, not specific to openMSX. There are various solutions to deal with off-screen windows. We could deal with this is openMSX itself (actually that would require changing the GUI toolkit itself, that's not directly under our control), but I'm not sure that would be a good idea: e.g. if you only temporarily (perhaps even by accident) disconnect your 2nd monitor, you might not like that all windows then automatically move to the primary monitor.

Not always the second monitor is available. It happened that last weekend I took the laptop with me and made a trip to a place where no monitors were available.

Maybe, could it be somehow solved by adding a TCL command/script that moves all the floating windows to the centre of the active screen? Something like bring_all_windows_here. Or even better, it would be fantastic to have a tcl class to manipulate windows (something like UI::whatever) to cover this and other UI-related features in the future.

And I haven't tried, but maybe CTRL+TAB can help you find back missing windows???

I've tried but it just set the focus on the off-screen window.

• There's no option to decorate all window titles. But this would also have been a problem with the old debugger. So it's not a regression (at the moment the focus is on fixing regressions). And many

When using the classic debugger UI, I usually save the session with a descriptive name. Thus, I can read the decoration bar to know where I am. I haven't still found how to do this on the new UI.

• Key binding issue. Was already discussed before. Still same status.

Ah, did you notice the new options "Settings > GUI > Save layout" and "Restore layout". At the moment these are still experimental. But it could be a partial solution or a workaround for the first two problems.

While this option is not a solution for these issues, it is still a very nice feature that I'm sure I'll find quite useful in a near future.

Thank you for your support.

[gilbertfrancois]

I noticed a small inconsistency in the file choosers:

Symbol Manager -> Load symbol file -> ImGuiFileDialog needs one click to go into the next folder
Media -> Disk drive A -> disk image -> ImGuiFileDialog needs one click to go into the next folder
Media -> Disk drive A -> dir as disk -> ImGuiFileDialog needs two clicks to go into the next folder

I guess this behavior is intended, because the first 2 options are for selecting files and the last option is for selecting folders (which is impossible if you go with one click into a folder)? I found it a bit confusing and unexpected. Maybe it would be a good idea to have double click to go to the next folder in all FileDialog modals. It is also the default behavior in most operating system.

Would that be as simple as adding the flag ImGuiFileDialogFlags_DisableQuickPathSelection when calling ImGuiFileDialog::openDialog or is this quick path the path breadcrumb on the top of the dialog?

[m9710797]

Hi gilbertfrancois,

Thanks a lot for your feedback!

You're right and, at first, i also found this confusing. But the difference is indeed selecting a file versus selecting a directory.
Unfortunately the ImGuiFileDialogFlags_DisableQuickPathSelection flag is poorly documented. I'll test in more detail this evening (I'm at work now) but a (very) quick glance at the source code tells me it's indeed related to path selection at the top, and not the double-click behavior on the file/directory list.

I agree it's unfortunate, but also not too bad (IMHO). And my preference is, at least for now, to not start making changes in 3rdpart code like ImGuiFileDialog (this would make upgrading to newer versions in the future much more difficult).

But thanks for reporting. Keep the feedback coming.

Wouter

[ocornut]

Assuming you are up to date, I think you can probably start looking at the ImGui::Shortcut() function and how the input routing system works.
I am open to answer dedicated/focused questions on imgui repo about how to solve certain problems (but unfortunately have too many things on my plate to e.g. be actively reading third-party threads such as this one in details).

[MBilderbeek]

• Still, the lack of proper key bindings for the debugger UI is a big problem. Most of the time I use a laptop with a small keyboard and haven't many keys left to waste for this. A priority-based or focus-based set of keybindings is definitely necessary here.

This has now been solved, please take a look and comment on whether that's sufficient. (Indeed using ImGui::Shortcut() thanks to @pvmm ).

[Colpocorto]

• Still, the lack of proper key bindings for the debugger UI is a big problem. Most of the time I use a laptop with a small keyboard and haven't many keys left to waste for this. A priority-based or focus-based set of keybindings is definitely necessary here.

This has now been solved, please take a look and comment on whether that's sufficient. (Indeed using ImGui::Shortcut() thanks to @pvmm ).

Tested and working. F4 and F12 are shift-F7 and shift-F8 now (what it's fine).
Thank you very much for the efforts.

[MBilderbeek]

Thanks! For all different other issues, can you please re-evaluate and open separate issues for each one, if they still apply?

[Colpocorto]

Thanks! For all different other issues, can you please re-evaluate and open separate issues for each one, if they still apply?

I will during the weekend. I've also found some annoyances related to window docking. Will create separate ticktets soon.

[Colpocorto]

Just one more thing about the key bindings. I miss F9 to continue execution. Can it be added?
Also, "Run to" (F4) is something I use intensively on the classic debugger.

EDIT: it seems that it is F5 now instead of F9. Bad choice. F5 to run is Microsoft-style while F7/F8 to step in/over is classic Borland binding (the one used on OpenMSX debugger since its inception).
I suggest to stick to one of the two flavours but not to mix both of them. For those who work with MSVS or IntelliJ in real life, this can cause a mental mess!

[m9710797]

I've added a shortcut for "run to address". Similar to the "scroll-to address" function, it opens the (right-click) context menu and sets keyboard focus on the appropriate field.

I understand that it can be annoying that we don't follow existing debugger shorcut conventions. Though one practical problem we have is that many keys (e.g. F9-F12) are already in use by openMSX itself. For example F9 is bound to "toggle throttle" and it has been for 15, maybe 20, years, people are used to this. I think most openMSX users don't use the debugger. So we have to make a tradeoff between following common debugger conventions and not breaking the workflow of existing openMSX users (who maybe aren't interested in the debugger).

You can of course edit the shortcuts and set them to your preferences. And if you have concrete suggestions for better default shortcuts then please share. But do keep the existing openMSX hotkey bindings in mind.

[Colpocorto]

I've added a shortcut for "run to address". Similar to the "scroll-to address" function, it opens the (right-click) context menu and sets keyboard focus on the appropriate field.

I understand that it can be annoying that we don't follow existing debugger shorcut conventions. Though one practical problem we have is that many keys (e.g. F9-F12) are already in use by openMSX itself. For example F9 is bound to "toggle throttle" and it has been for 15, maybe 20, years, people are used to this. I think most openMSX users don't use the debugger. So we have to make a tradeoff between following common debugger conventions and not breaking the workflow of existing openMSX users (who maybe aren't interested in the debugger).

You can of course edit the shortcuts and set them to your preferences. And if you have concrete suggestions for better default shortcuts then please share. But do keep the existing openMSX hotkey bindings in mind.

Don't get this. Also F7 and F8 are bound to OpenMSX itself (SELECT and STOP) but yet you've managed to assign them to the debugger. Can't the key binding just be overriden when the execution is stopped and then restored to their original function once the emulator continues execution?

[m9710797]

We have several levels of input handling. I'll try to give a (simplified) overview:

• At the highest level we have "hotkey" bindings. This is the mechanism controlled via the "bind" command. It already existed in openMSX version 19 and before. This handles stuff like F9 "toggle throttle" or F11 "toggle mute". These bindings are always active.
• In the current development version we added ImGui integration (this is the new GUI). This layer is active whenever one of the GUI windows has focus (so all windows except for the main openMSX window). This layer handles stuff like GUI mouse and keyboard input (clicking on button, typing in input fields) but also GUI shortcuts (configurable via 'Settings > GUI > Edit shortcuts'). (Some of) these shortcuts can be either global (=always active when some GUI window has focus) or local to one specific GUI window (=only active when that specific GUI window has focus).
• The last layer is the MSX input layer, e.g. the MSX keyboard, mouse, joystick. This layer is only active when none of the above captured the event. So when it's not bound as a hotkey and none of the GUI windows has focus.

So, currently, because F9 is (by default) bound to a hotkey it's not possible to also use it as a GUI shortcut (or at least the shortcut will never trigger). On the other hand it is possible to use the same keys for GUI shortcuts and for MSX keys (e.g. F7), because we can know whether to pass the event to the GUI (when a GUI window has focus) or to the MSX (when the main openMSX window has focus).

[Colpocorto]

Thank you for the detailed explanation, that explains everything.

Thank god the classic debugger still works :)

[MBilderbeek]

Can you make really explicit what you need the old debugger for, which you cannot do with the new one?

[Colpocorto]

Use a classic keymap I am accustomed to (not only on OpenMSX but also on IntelliJ, Lazarus and other IDEs). Since I can't find any advantage to use the new GUI, I will remain stuck to the classic one as long as I feel comfortable with it. I will stay tuned though since I understand this might change in the future.

[MBilderbeek]

Well, you can still customize it to your needs and use whatever key bindings you want. You might have to change the global openMSX binds as well though, as Wouter explained.

[ocornut]

I imagine it should be possible with a bit of rework to tweak the wiring so the GUI shortcuts used by debugger are prioritized when debugger is active? Seems solvable.

On this old idea:

So if you want to stop register updates, you'll just have to pause the emulation (and then maybe fast-forward after unpausing). I believe that for the majority of the users/use-cases having real-time updated views is more useful than viewing snapshots (I mean while the emulation is also running). Especially for e.g. the bitmap/tile/sprite-viewer, but also for the register view (e.g. watch a delay-loop count down in real-time, or see at a glance how the SP varies during typical execution).

If that’s deemed valuable for some users later you could take a state snapshot when resuming emulation and have an option to use state from that snapshot. But i tend to agree seing the live version is more desirable most of the time.

[Colpocorto]

Well, you can still customize it to your needs and use whatever key bindings you want. You might have to change the global openMSX binds as well though, as Wouter explained.

I would do it if I hadn't other options. Luckily enough, I can use the old debugger and I will.

[ocornut]

I would do it if I hadn't other options. Luckily enough, I can use the old debugger and I will.

If I may say so, and I am merely an onlooker here, you could be more cooperative considering this is a hobbyist project trying to move forward. I feel if you put a little more energy using the tool, your feedback would be useful and the author would be more motivated to fix issues.

[Colpocorto]

I would do it if I hadn't other options. Luckily enough, I can use the old debugger and I will.

If I may say so, and I am merely an onlooker here, you could be more cooperative considering this is a hobbyist project trying to move forward. I feel if you put a little more energy using the tool, your feedback would be useful and the author would be more motivated to fix issues.

Hmmm. Why don't you think I am cooperative? Unlike many other users, I have reported tons of bugs, observations and suggestions.

But, if at this stage of the development I feel more comfortable with the old UI, I will use it in a regular basis. Can't see what's wrong with that. Of course, I will continue testing the new development and leaving my findings here.

[ocornut]

Sorry for meddling, this is not my project, i’ll let maintainers do their thing :)

[MBilderbeek]

Well, you can still customize it to your needs and use whatever key bindings you want. You might have to change the global openMSX binds as well though, as Wouter explained.

I would do it if I hadn't other options. Luckily enough, I can use the old debugger and I will.

That's fine of course. But please keep in mind that it's not very likely that we'll do any more work on the old debugger. Our focus will be on the new one in openMSX itself and I don't expect any time to get spent on the old one anymore. So, if it breaks due to some reason, it is not likely to get repaired.

Please do me a favour and try to use the new debugger every now and then to be able to keep giving your valuable feedback to us on our actively developed software :)

[Colpocorto]

Please do me a favour and try to use the new debugger every now and then to be able to keep giving your valuable feedback to us on our actively developed software :)

Sure, I will continue testing the new software and reporting my feedback (even if for my personal use I stick to older versions of OpenMSX).