Debugger keybinding

[cacb]

I have been using MS Visual Studio for many, many years and have grown accustomed to the MS debugger keybindings. Actually, the Visual Studio debugger is rather good too, so that is one reason I have been using the MSVC compiler in Code::Blocks. I have simply created a simple tool that launches the Visual Studio GUI when debugging my Code::Blocks projects on Windows. Therefore, my keybinder habits remain, i.e. mostly these

   MSVC       C::B           Description
   ----       ----           -----------
   F5         F8             Start/Continue
   F10        F7             Next Line
   F11        Shift+F7       Step Into
   Shift+F11  Shift+Ctrl+F7  Step Out

Now that the C::B debugger has improved in many ways, I'd like to try and use it more, especially under Linux. The default keybinding for the debugger remains an obstacle though, I would like to continue using the MSVC keybinding scheme, as I am so used to it and find the C::B scheme a distraction when debugging.

So I would like to configure the debugger keybindings according to the MSVC scheme shown above (list is not complete). It seems to me I have no way to redefine the debugger keybindings in C::B, but I may have overlooked some way to use the Keybinder plugin or something like that? Is there a config file for this somewhere?

[zabzonk]

Settings|Editor|Keyboard Shortcuts, and then select the Debug commands from the tree.

[oBFusCATed]

cacb: unfortunately f10 is a reserved key in gtk, so it can't be used...

[cacb]

@Neil
That is a wonderful reply, thanks a lot. I noticed you have to have the debugger plugin enabled for the debugger commands to be visible in that tree. Not a big surprise.... but I had it disabled in Windows 

@oBFusCATed
You are obviously right that F10 keybinding is a problem in Code::Blocks. I am running under KDE (Kubuntu 12.04) and I was able to assign all the keys listed, including F10 following Neil's description, see screenshot of my Debug menu under KDE now. However, it doesn't work, as you say. I would say that is a bug in one way or another: Either it should work or it should be disallowed.

And I don't see why it should not work: I don't think it is generally true that F10 can't be used by applications under KDE (is there a distinction between KDE and 'gtk' here?). I just looked around in some other KDE programs, and I can't see they behave like this. For example, the KDE Text Editor 'Kate' actively uses F10 keyboard shortcut for toggling 'Dynamic Word Wrap' in its View menu. No problems at all.

If at all possible I would prefer if Code::Blocks disabled (or allowed me to disable) such menubar shortcuts that I never use anyway. They just get in the way of the more important debugger configuration.

Possible?

[cacb]

Another problem observed is that Shift+F11 does not seem to work as specified. When that keybinding is assigned to the Debug|Step Out function as I did, it works exactly as F11, i.e. as Debug|Step into. That looks like a bug.

Selecting Debug|Step Out with the mouse in the Debug menu works fine.

Out of 4 keybindings attempted, 2 fail. If they all worked, it would be a very nice solution to the debugger keybinding issue. But as it is, it isn't usable for what I attempted.

Btw. under Kubuntu I am running Nightly Build svn 8133 from http://apt.jenslody.de/stable

[Jenna]

You might use KDE, but C::B itself uses wxWidgets as framework anfd wxWidgets is build against gtk on (almost) all linux platforms.

[oBFusCATed]

Another problem observed is that Shift+F11 does not seem to work as specified. When that keybinding is assigned to the Debug|Step Out function as I did, it works exactly as F11, i.e. as Debug|Step into. That looks like a bug.

I have the same problem and I think this is system wide or at least gtk-wide and it is related to xkeyboard-config.

[cacb]

You might use KDE, but C::B itself uses wxWidgets as framework anfd wxWidgets is build against gtk on (almost) all linux platforms.

You are right. I checked my own wxWidgets program and it reacts to F10 by popping up the File menu, just like Code::Blocks, even if wxWidgets and the application was compiled, built and run under KDE. That is a bit unfortunate. Maybe I will investigate this....

I have compiled wxWidgets against gtk as well, so I guess that explains part of it (I am aware this does not affect C::B, but I guess it is similar fro the C::B build I am using)

Code

wx-config --version=2.8 --toolkit=gtk2 --debug --cxxflags

Somehow, it would be nice if one could replace --toolkit=gtk2 with --toolkit=kde and get the proper behaviour.

It appears to be a known complaint with gtk: gtk and F10

[oBFusCATed]

Somehow, it would be nice if one could replace --toolkit=gtk2 with --toolkit=kde and get the proper behaviour.

There is port of wxwidgets to qt (the toolkit used to build kde), but I'm not sure it will ever be released...

[Jenna]

Somehow, it would be nice if one could replace --toolkit=gtk2 with --toolkit=kde and get the proper behaviour.

There is port of wxwidgets to qt (the toolkit used to build kde), but I'm not sure it will ever be released...

And it will most likely not be possible to build C::B out of the box with it.

[cacb]

Somehow, it would be nice if one could replace --toolkit=gtk2 with --toolkit=kde and get the proper behaviour.

There is port of wxwidgets to qt (the toolkit used to build kde), but I'm not sure it will ever be released...

And it will most likely not be possible to build C::B out of the box with it.

I asked about this issue on the newsgroup gmane.comp.libwxwindows.general and got a promising reply from several people, among them this one from Eran Ifrah

This is how I do it in codelite IDE (for the exact same purpose: F10 for the debugger ) :


#if  defined(__WXGTK20__)
// A rather ugly hack here.  GTK V2 insists that F10 should be the
// accelerator for the menu bar.  We don't want that.  There is
// no sane way to turn this off, but we *can* get the same effect
// by setting the "menu bar accelerator" property to the name of a
// function key that is apparently legal, but doesn't really exist.
// (Or if it does, it certainly isn't a key we use.)
gtk_settings_set_string_property (gtk_settings_get_default (),
                                 "gtk-menu-bar-accel", "F15", "foo");


#endif

I have tried a few other things, including modifying a local ~/.gtkrc under KDE, but it didn't work.

I would suggest an option implemented in C::B doing the above, preferably in a way that didn't requiire the user to recompile the IDE. That way, C::B could be more KDE-compliant, and we could reclaim F10 for the debugger (or anything else).

[oBFusCATed]

I would suggest an option implemented in C::B doing the above, preferably in a way that didn't requiire the user to recompile the IDE. That way, C::B could be more KDE-compliant, and we could reclaim F10 for the debugger (or anything else).

What about talking to the gtk devs to make their toolkit more kde compilant?

p.s. I think this hack have been posted already on the forum.

[cacb]

I would suggest an option implemented in C::B doing the above, preferably in a way that didn't requiire the user to recompile the IDE. That way, C::B could be more KDE-compliant, and we could reclaim F10 for the debugger (or anything else).

What about talking to the gtk devs to make their toolkit more kde compilant?

Be my guest.  Until that is accepted, my suggestion remains.

p.s. I think this hack have been posted already on the forum.

I have searched, but had not seen it.