On Friday, 26 April 2019 at 14:50:17 UTC, Mike Wey wrote:
On 26-04-2019 10:31, Amex wrote:
When debugging under visual D, the keyboard response is slowed
down to the extreme. This is a Gtk issue I believe. It only
has to do with the keyboard.
For example, if I hit F10 to step, it takes the ide about 10
seconds to "respond" and move to the next line... yet the
mouse can access stuff instantaneous.
I believe Gtk or GtkD is slowing down the keyboard input
somehow and for some reason making debugging apps a nightmare
since it literally takes about 100 times longer to debug than
it should.
searching google reveals:
https://github.com/Microsoft/vcpkg/issues/4529
https://developercommunity.visualstudio.com/content/problem/42018/debugging-with-keyboard-very-slow.html
"You somehow break keyboard shortcuts during debugging in VS
if the application you're debugging is registering a callback
with "SetWindowsHookEx" from user32.dll with hook ID
"WH_KEYBOARD_LL".
Don't call it in debug builds or add "if
(!Debugger.IsAttached)" in front of the call to
"SetWindowsHookEx" if the debugger is attached before the
function is called.
This brings debugging with keyboard back to the same speed as
with the UI buttons for our application."
This seems to be an issue with Gtk. I'm not sure if GtkD can
do anything about it. Maybe somehow reroute the keyboard
handler(first remove it from the hook then call it manually or
reduce the number of calls to it).
I can confirm that gtk call "SetWindowsHookEx" with the
"WH_KEYBOARD_LL" ID upon initialization.
As far as i can tell it doesn't provide a way to skip this.
Any news about this? Do you think it can be fixed in some way?