Hi guys.
When I use C::B for code editing, all keyboard shortcuts work as expected. But when I try to edit documents which require keyboard layouts other than Latin (Cyrillic in my case), the shortcuts are not recognized as such anymore. I made an attempt to just add the Cyrillic variants, such as Ctrl+Я for Ctrl+Z, but also failed: the shortcut plugin doesn`t seem to recognize Cyrillic keystrokes at all.
Please help. Having to switch layouts back and forth while editing happens to be very frustrating.
Build: Dec 16 2018, 16:24:23 - wx3.0.4 (Linux, Unicode) - 64 bit - svn 11530
What are your locale settings?
What is the exact layout you're using?
Which version of wxgtk do you have the one linking to gtk2 or gtk3?
I'm using Bulgarian phonetic layout and shortcuts work fine when using wxgtk3.0.4 and gtk2.
I've also tested the gtk3 version and it works fine, too.
Does shortcuts work correctly in other gtk2 or gtk3 programs when using the Cyrillic layout?
Quote from: oBFusCATed on March 23, 2019, 04:51:58 PM
What are your locale settings?
What is the exact layout you're using?
$ locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=
$ setxkbmap -query | grep layout
layout: us,ru
Quote from: oBFusCATed on March 23, 2019, 04:51:58 PM
Which version of wxgtk do you have the one linking to gtk2 or gtk3?
I'm using Bulgarian phonetic layout and shortcuts work fine when using wxgtk3.0.4 and gtk2.
I've also tested the gtk3 version and it works fine, too.
$ ldd $(which codeblocks) | grep wx
libwx_gtk2u_aui-3.0.so.0 => /usr/lib/libwx_gtk2u_aui-3.0.so.0 (0x00007f7a11c1c000)
libwx_gtk2u_propgrid-3.0.so.0 => /usr/lib/libwx_gtk2u_propgrid-3.0.so.0 (0x00007f7a11b2e000)
libwx_gtk2u_xrc-3.0.so.0 => /usr/lib/libwx_gtk2u_xrc-3.0.so.0 (0x00007f7a11a2b000)
libwx_gtk2u_html-3.0.so.0 => /usr/lib/libwx_gtk2u_html-3.0.so.0 (0x00007f7a11956000)
libwx_gtk2u_qa-3.0.so.0 => /usr/lib/libwx_gtk2u_qa-3.0.so.0 (0x00007f7a11925000)
libwx_gtk2u_adv-3.0.so.0 => /usr/lib/libwx_gtk2u_adv-3.0.so.0 (0x00007f7a11744000)
libwx_gtk2u_core-3.0.so.0 => /usr/lib/libwx_gtk2u_core-3.0.so.0 (0x00007f7a110fe000)
libwx_baseu_net-3.0.so.0 => /usr/lib/libwx_baseu_net-3.0.so.0 (0x00007f7a110b6000)
libwx_baseu-3.0.so.0 => /usr/lib/libwx_baseu-3.0.so.0 (0x00007f7a10e13000)
libwx_gtk2u_richtext-3.0.so.0 => /usr/lib/libwx_gtk2u_richtext-3.0.so.0 (0x00007f7a1073b000)
libwx_baseu_xml-3.0.so.0 => /usr/lib/libwx_baseu_xml-3.0.so.0 (0x00007f7a10728000)
Quote from: oBFusCATed on March 23, 2019, 04:51:58 PM
Does shortcuts work correctly in other gtk2 or gtk3 programs when using the Cyrillic layout?
Yup. Both GTK2 and GTK3 handle shortcuts just fine, regardless of the layout — except in C::B, that is.
Do you have the keybinder plugin loaded in C::B? What happens if you unload it?
Does shortcuts work in some other wxgtk programs?
No, unloading the keybinder doesn`t help.
And yes, shortcuts in text fields (e.g. Ctrl+A in the search field of AMule or Ctrl+Z/Ctrl+Y in wxHexEditor) do work.
This is really strange. In theory gtk should be responsible for shortcut handling and then it has to pass them to wx and finally C::B gets events from wx for the particular menu command.
Does shortcuts work in text fields in C::B it might be related to our version of wxScintilla...
Can you try to reset the locale locally to en_US.UTF8 and see if this fixes it?
For example start cb from a terminal where you've modified the locale.
Would it be possible to try 17.12 or 16.01?
Quote from: oBFusCATed on March 23, 2019, 07:29:46 PM
Can you try to reset the locale locally to en_US.UTF8 and see if this fixes it?
After a system-wide locale reset the problem is still here. Tested on both my SVN build and the stock 17.12.
Quote from: oBFusCATed on March 23, 2019, 07:29:46 PM
Does shortcuts work in text fields in C::B
Yes! IncrementalSearch accepts Ctrl+A even when the layout is Cyrillic.
Hm, I can reproduce ctrl-a not working in the editor when in bg layout, so I guess the problem is only with shortcuts created inside scintilla...
Can you confirm? Does ctrl-z, ctrl-o or ctrl-s work for you? They work for me. Only ctrl-a doesn't.
Yes, all three. But e.g. Ctrl+Y, Ctrl+C, Ctrl+V do not.
Is there some quick fix for that?
No idea, I have to inspect the wxSTC/wxscintilla code to find out if is getting the proper codes.
You can try the stc sample in wx and if it reproduces you can report a bug in the wxwidgets project. There might be someone which could look at the problem faster.
Cloned the latest revision of wxWidgets from Github, built the STC sample.
Behaves as expected — all shortcuts work, regardless of the layout.
This is not true. the stcedit has the same problem.
You think it works because more shortcuts are specified for menus for the stcedit sample.
Try ctrl-shift-u and ctrl-u and you'll see they don't work. These two make the selection all upper case and all lower case.
Please log an issue for wxwidgets and give me the link. I'll either follow it and if I find time I'll try to fix it.
An easy workaround/fix for some commands: is to specify a menu short cut using the keybinder plugin.
OK, I can confirm that Ctrl+U / Ctrl+Shift+U shortcuts do not work in Cyrillic layout.
Unfortunately I cannot register in wxWidgets` TRAC to create a ticket =(
For the fourth time I`m told that "a notification email has been resent" but nothing appears in my inbox.
OK, I'll try to log the issue on your behalf...
Ticket posted https://trac.wxwidgets.org/ticket/18370
Heads up, I`ve got news!
This is where the error seems to happen:
int ScintillaWX::DoKeyDown(const wxKeyEvent& evt, bool* consumed)
{
int key = evt.GetKeyCode();
if (key == WXK_NONE) {
// This is a Unicode character not representable in Latin-1 or some key
// without key code at all (e.g. dead key or VK_PROCESSKEY under MSW).
if ( consumed )
*consumed = false;
return 0;
}
...
WxWidgets Scintilla implementation processes shortcuts not by the keyboard scancode as it needs to be, but by the actual character typed!
Do you guys know how to retrieve scancodes from a wxKeyEvent ?
Update: found it! It`s called wxKeyEvent::GetRawKeyCode() (http://wxd.sourceforge.net/wxWidgets-2.8.4/docs/html/wx/wx_wxkeyevent.html#wxkeyeventgetrawkeycode), but its results are platform dependent. Okay that`s fine, I`ve already collected the scancode tables for Windows (https://github.com/hidefromkgb/msu3-waves/blob/56f18c6e2c4ccaadfed01f9dfa8c245d5d2b9155/win32/main.c#L14), Linux (https://github.com/hidefromkgb/msu3-waves/blob/56f18c6e2c4ccaadfed01f9dfa8c245d5d2b9155/linux/main.c#L71) and MacOS (https://github.com/hidefromkgb/msu3-waves/blob/56f18c6e2c4ccaadfed01f9dfa8c245d5d2b9155/macos/main.c#L48) =)
Please post any of these in the wx's trac...
Here they would get lost...
Can I just post a .DIFF patch to wxTRAC?
Something tells me I`m capable of fixing that problem all by myself.
Yes, you can.
Done! PR #1305 (https://github.com/wxWidgets/wxWidgets/pull/1305).
...Guys, would it be too much if I asked you to apply that patch to C::B ahead of the WXW trunk?
Granted, I can just take the source and do that myself, but it`d be way cool if that bugfix made it to C::B, for I doubt I`m the only one experiencing that problem.
I'm hesitant to do it, because syncing the source is already hard and applying this patch it will make it harder.
I guess New Pagodi could help test the patch?
Fix applied!
https://github.com/wxWidgets/wxWidgets/commit/bc1295fbdc2849013333c7107c5abfc4a04ac6b0
I'll pick the change next time I update wxscintilla...
In svn...