GNOME Bugzilla – Bug 453068
Third-party Latvian keyboard input software not supported
Last modified: 2016-11-25 18:10:01 UTC
On GnuCash (v2.1.4, built from r16170 on 2007-06-18) version for MS Windows (WinXP Pro, SP2) cannot correctly enter local language (Latvian) specific characters by keyboard in any text field within any GUI component, including Account Register Window, New/Edit Account, Transfer Funds. It is possible to enter text correctly by writing and copying it in external text editor (for instance, Notepad) and then pasting in GnuCash. It is also Ok to import, for example, OFX file with specific Latvian chars in UTF-8 format. In either case (copy/paste or file import), data is then stored, retrieved and displayed correctly. To reproduce: 1. Enable language bar (right-click Windows task bar, check Toolbars->Language bar); 2. Right-click keyboard icon in Language bar, add to 'Installed Services' input language 'Latvian' and keyboard layout 'Latvian (~)'; 3. Now one should be able to choose 'Latvian (~)' by left-clicking keyboard icon in Language bar and after that able to input specific chars (to get specific char push an release tilde key ([~] near [1]) and after that corresponding 'regular' char, for instance, keyboard sequence [~][a] should yield 'a' char with dash above it.
Created attachment 91019 [details] Illustration in Account Register Window
Created attachment 91020 [details] Illustration in Account Window Data is stored, retrieved and displayed correctly.
Created attachment 91021 [details] Illustration in Transfer Funds Window
Created attachment 91022 [details] Upper case chars
Created attachment 91023 [details] Lower case chars
Created attachment 91024 [details] Retrieved and displyed in reports
Hm, I do not have a latvian keyboard. Following your steps, I was able to add 'Latvian' and 'Latvian (QWERTY)' as keyboard, choosing the primer one. No 'Latvian (~)' though. I typed all sorts of keys on my german keyboard and found some of your characters. Please see the next attachment---it was all done without copy&pasting, I used the native GnuCash widgets only. So I wonder whether this is a problem in GTK+. Could you please try to type in * Gnumeric, or * gtk-demo > Text Widget > Hypertext, by extracting ftp://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.10/gtk+-dev-2.10.11.zip into your GnuCash folder.
Created attachment 91193 [details] My register, showing chars correctly
I have tried to play with "gtk-demo > Text Widget > Hypertext" and I've got the same results as in GnuCash. I have also got similar (partial) results with simple 'Latvian' and a little worth results with 'Latvian (QWERTY)', which I guess are MS Windows built-in/supplied layouts. And here comes the worst - 'Latvian (')' and 'Latvian (~)' I guess are supplied by different vendor by installing additional copyrighted languages tools :( I shall attach screenshot of About dialog.
Created attachment 91194 [details] Keyboard layouts and additional software
Looking at http://www.tilde.lv/English/portal/go/tilde/3777/en-US/DesktopDefault.aspx, I cannot see a download link and suppose I would need to buy it. And a latvian keyboard as well. Redirecting the bug to gtk+ / input methods.
GTK+ can not attempt to support random 3rd party keyboard layouts and keyboard input software. Especially not commecial layouts or software that would cost money to test. Even supporting all Microsoft's keyboard layout is not 100%, for instance the Czech keyboard layout is known to have some inaccuracies due to the exotic behaviour of the CapsLock key for the "number row" in that layout. See bug #165385. I think also the Canadian Multilingual keyboard layout might be problematic. Microsoft's keyboard layouts are presented with useful on-line demo mini-keyboard popups (unfortunately they work only in IE) at http://www.microsoft.com/globaldev/reference/keyboards.mspx. What's wrong with the Latvian keyboard layout(s) Microsoft supplies? As far as I could see, I am able to enter all the same Latvian characters into GTK+ as I can into WordPad using Microsoft's "Latvian (QWERTY)" layout. (I didn't try the layout called just "Latvian" which seems to match what Wikipedia calls the "ergonomic" layout".) (This does not include capital or small O with macron, though. Wikipedia says that letter "has not been used in the official Latvian language since 1946." Is this letter still often needed?) Are you claiming that Microsoft's official keyboard layouts are in fact widely not used in Latvia? Has nobody bothered to inform Microsoft about this then so that they could have fixed them? Do you claim that "everybody" in Latvia in fact uses this 3rd-party commercial(?) keyboard layout?
I think that problem is how "dead key" is treated in gtk+, and not in the third-party software or keyboard layouts. After reading http://www.microsoft.com/globaldev/handson/dev/Unicode-KbdsonWindows.pdf mentioned in bug #165385, I did a little experiment. I downloaded Microsoft Keyboard Layout Creator from MS homepage (it requires genuine Microsoft Windows) and created my own layout. It works fine in Windows, but fails within gtk+. According to above mentioned Unicode-KbdsonWindows.pdf, the dead key mechanism is mostly used in European keyboard layouts, so this is not specific to Latvian only. Most of the Latvian people I know use exactly dead key mechanism. I shall attach keyboard layout source, which could be used by Microsoft Keyboard Layout Creator to create and later install keyboard layout which uses TILDE (~) dead key to enter specific characters.
Created attachment 91662 [details] Keyboard layout source
The dead keys used in for instance Microsoft's Finnish keyboard layout work fine in GTK+, so it isn't so that dead keys in general wouldn't work. In the Latvian (QWERTY) layout, the "degree sign" key, three keys to the right of the "L" key, should act as a dead key together with a A e E g z and Z, producing å Å ė Ė ġ ż and Ż, but it works only with a and A in GTK+. In WordPad it works as it should. So this is at least one clear bug also in the support of Microsoft keyboard layouts. But this bug is then in the cross-platform part of GTK+ which is where dead keys are handled. (I didn't recall that yesterday when commenting on this bug.) The table in gtkimcontextsimple.c has entries for GDK_dead_abovering only when followed by A, U, a or u. I think there are already bugs open for completing the table in gtkimcontextsimple.c, hopefully they include also handling the Latvian cases of dead_abovering. (Actually I don't understand why the code can't just automatically accept *any* sequence of a dead key followed by a letter that has a well-defined meaning and maps to a precomposed Unicode character? Why do these cases have to be listed explicitly? In the Latvian case, though, that would handle only å and Å, dead_abovering followed by e E g z and Z would still have to have explicit mappings to ė Ė ġ ż and Ż.) Could you run gtk-demo (or some other GTK+ application) with the Latvian 3rd-party keyboard thingie active, having set the GDK_DEBUG environment variable to the value "events", with standard output redirected to a file, thanks? I.e. in a command prompt, assuming your PATH is set up correctly, enter the command: set GDK_DEBUG=events gtk-demo >gtk-demo.out.txt Then double-click on the "Entry completion" and type some of the problematic sequences. Then edit gtk-demo.out.txt, and remove all other lines except those that contain the strings WM_KEYDOWN, WM_KEYUP, GDK_KEY_PRESS or GDK_KEY_RELEASE. Then attach that log file to this bug. Thanks.
Created attachment 91665 [details] Output of GDK_DEBUG="events" with custom/3rd party keyboard layout
So the dead key you push here is "grave" (`), right? At least with the vocals e, u, i and o GTK+ should know to combine it to produce è, ù, ì and ò. But I guess that is not what you expect... Will have to install that keymap and dig deeper into this issue. Presumably this issue can't be resolved by working only on the Win32-specific code, though, as it is the upper level of GTK+ that handles dead keys. Btw, you didn't answer why the Latvian keyboard layouts shipped by Microsoft aren't good enough? Is the use of that 3rd-party keyboard software and/or layout (which one is it?) widespread in Latvia (also outside "hacker" circles, in normal office work using Windows)?
I am having similar problem but not with dead keys. I have created my own programmer keyboard layout years ago and as far as I know it has never worked in any GTK+ application. My keyboard layout is called CShack and * has no dead keys * has no Lock keys * has one new 'shift' key added placed instead of CapsLock - is called CShack * almost every key has two new characters added when CShack pressed (without and with Shift key) Without pressing CShack (former CapsLock) it works as an ordinary US keyboard. You can see what happens after pressing CShack here http://xakru.com/cshack/LayoutA.gif . In short - this layout includes all Czech, Slovak, German, Spanish and many DTP characters. I use this layout daily and it works perfectly in every windows application except GTK+ applications - they simply ignore pressed CShack. The main part of CShack - windows driver has been built from C source code and this is freely available here http://xakru.com/cshack/sources/kbdCShack.c . The source code is simple and has two main functions: map virtual scan codes to virtual keys and then map virtual keys to WCHAR translations according to current shift states. All is organized as structured tables in tables defining output Unicode character. I wonder why GTK+ doesn't simply accept emitted Unicode character? Or where is the problem?
> it works perfectly in every windows application You have tried them all? Amazing.
(In reply to comment #19) > > it works perfectly in every windows application > You have tried them all? Amazing. Yes, you are right. Nobody can try every windows application. But I have tried and still use many windows applications without any problem (there are only problems with non-Unicode applications and characters not included in "their" encoding). And the same experience have users of my keyboard writing me in response something like this: I set CShack as my primary keyboard layout, I made my wife not use any other keyboard layout, I have uninstalled any other installed layouts, All my family use this layout (I'm not joking :-) and I still can't use this layout in Gimp... This is not a big problem for me, I use shortest accessible windows edit control (mostly Run) + clipboard. But this could be unnecessary drawback for many GTK+ users... One of them made me report this problem.
This bug is set to NEEDINFO for quite some time now, since comment #7. As far as I can see, the question, which was raised back then, has been answered since. I am thus reopening this bug.
The same for GIMP. This is real problem which bothers Latvian windows GTK software users. Few things to clarify: 1) Windows built-in layout Latvian(QWERTY) is not popular, because it uses "alt" as dead key. Before Microsoft started to ship Latvian(QWERTY) layout, there was 3rd party commercial layout called TILDE which used either (~) or (') as dead keys so it got mainstream use many years before MS started to ship their Latvian(QWERTY) layout... Some people belive that there was MS - TILDE agreement so that MS supports only unpopular "alt" dead key, to preserve TILDE market share. 2) Some people belive that there is no way to type Latvian specific charters in GTK+ soft under windows, because GTK+ supports only Latvian(QWERTY) layouts "right alt", while people accustomed to use "left alt". You can test, that Latvian(QWERTY) layout works in any other windows programm with booth dead keys - "left and right alt", but in GTK+ only with "right alt". Maybe this could be resolved? 3) There is also available uncommercial (') and (~) layouts which are mainly used: http://laacz.lv/apostrofs/ Maybe developers could use this version and bring in support? :) 4) There are a bunch of 3rd party windows programms which works fine with every different layout, why is GTK+ so special on windows? (Works like a charm on X11) Thank you!
> why is GTK+ so special on windows? Feel free to investigate the source code.
No offence Tor ;]
You talk about "Alt" being a dead key. That is not the case. "AltGr" ("Right Alt" as you say) is not a dead key either, it is a modifier key. Looking at the Latvian QWERTY keyboard layout on Microsoft's http://msdn.microsoft.com/en-gb/goglobal/bb964651.aspx page (works only in IE), there are four dead keys on the keyboard: 1) The "Degree sign" key (three keys to thr right of "L" 2) The "Acute accent" key (AltGr+Apostrophe) 3) The "Diaeresis" key (Shift+AltGr+Apostrophe) 4) The "Tilde" key (Shift+Grave accent) Also, you claim that the Left Alt would work the same way as the AltGr key in other software. I don't see that in WordPad for instance. If I swtch keyboard layout to Latvian (QWERTY), typing AltGr+E produces ē while typing (Left)Alt+E opens the Edit menu. Typing AltGr+N produces ņ while typing (Left)Alt+N does nothing. GTK is different than most other software on Windows exactly because it originally was written for X11 and many of the concepts are based on how X11 works. For instance, the upper levels expect to get separate key press and release events.
You are right! Right Alt modifier (AltGr). (These other 4 dead keys are pretty useless for Latvian layout - symbols they produce are not in Latvian language) I will correct myself on that leftAlt thing: Pressing "CTRL+leftAlt" works the same as "AltGr" in non-GTK+ apps, but in GTK+ works only Altgr modifer. Thanks for your efforts!
Many years later this still is a big problem. Latvians still love apostrophe as a dead key and this prevents to use GTK+ applicaitons. I'd really love to Install Pidgin as internal chat tool in our company but since it uses GTK+ and we use apostrophe, it's just not possible. Just an example...
Fixing bug 569581 should fix most of the issues reported here. One that *isn't* fixed is the use of LeftCtrl+LeftAlt as a way to emulate AltGr (AKA RightAlt). This works in Windows applications, but not in GTK+. If that behaviour is wanted, please file a separate bug. *** This bug has been marked as a duplicate of bug 569581 ***