GNOME Bugzilla – Bug 617583
Dead accents keys don't work in GTK+ applications on OSX
Last modified: 2011-11-07 13:55:53 UTC
I tried several application in a MacOSX 10.6 (Snow Leopard) environment: - Gedit - Glade - Tomboy The ` appears without waiting for the vowel. (with TextEdit (OSX default editor) ` appears but It waits for the vowel)
Shouldn't the summary be more specific and say that is is the *dead* accent *keys* that don't work? Some keyboard have keys with "accented" letters on them, like 'Å', 'Ä' and 'Ö' on Swedish / Finnish keyboards. I assume these work fine, and it's just the dead accent mechanism that doesn't? (I put "accented" in double-quotes there, because in Swedish and Finnish, these letters are considered separate entities, not "accented". No native speaker thinks of 'Ä' as an 'A' with some accent or "umlaut", to use the German term. Visuall, it obviously is an A with two dots on top, but note that we indeed tend to just say "two dots", and not use some accentish term.)
Yeah Tor, you are right; ä and family work ok. I've changed the title now.
(In reply to comment #0) > The ` appears without waiting for the vowel. (with TextEdit (OSX default > editor) ` appears but It waits for the vowel) This is likely dependent on the keymap/keyboard layout that has been selected. (The "waiting" does not happen with the US layout). Many "special" characters can also be input using the alt key, which does not work in GTK+ applications either. My guess is that this is because there is no integration with / support for the Mac OS X input Methods.
Hello Kristian, I have a Spanish keyboard configured with the Spanish layout. If the info helps, the euro and cent symbols works ok (ALT+e and ALT+c).
Could someone please mark this as Confirmed? This always happens. I tried it with several combinations (different Macs, different installations, different keyboards). I use mainly a Portuguese keyboard. It makes GTK unusable for me in Mac OS X.
(In reply to comment #5) > Could someone please mark this as Confirmed? This always happens. I tried it > with several combinations (different Macs, different installations, different > keyboards). I use mainly a Portuguese keyboard. It makes GTK unusable for me in > Mac OS X. GTK+ developers don't make a distinction between UNCONFIRMED and NEW, so don't worry about the Status. Thanks for your input, though!
Comment 3 is correct, this can be fixed by implementing input method support for OSX. Although, if the Quartz gdk backend creates the expected key events for dead keys (GDK_dead_acute, etc), then the builtin simple input method should already handle this.
I'm currently experiencing this, for example, on Monodevelop. Is there any information I can provide you with that can possibly help dealing with this issue?
(In reply to comment #7) > Comment 3 is correct, this can be fixed by implementing input method support > for OSX. > Although, if the Quartz gdk backend creates the expected key events for dead > keys (GDK_dead_acute, etc), then the builtin simple input method should already > handle this. It seems to me that it would be better still to change the design a bit so that (UC)?KeyTranslate handles it directly. This can be managed by maintaining the "state" parameter between calls. The easy way would be to declare it static, and I think that that would be OK since Apple's event handling isn't thread-safe anyway. This should allow gtk-quartz users to use the same IMs that they use with the rest of their applications and protects us from "why doesn't my Thai IM work?" I'd refactor gdk_keymap_translate_keyboard_state() and maybe_update_keymap() into smaller functions and then create a "real-time" character retrieval function for fill_key_event(). As a second step, I'd reduce the keymap to only hold unmodified key-values, and store those in the key-hashes. That would make both writing and handling accelerators and bindings easier, because it would look to keyhash like <Cmd><Opt>t instead of <Cmd>þ. (Raise your hand if you can find "æ" on the keyboard without keyboard viewer. US Keyboards only, of course.) Localization of bindings and accelerators is a topic for a different bug. What am I missing?
Created attachment 175399 [details] [review] Add dead keys to the "special_ucs_table" This minor patch makes most of the european dead keys work "shifted". IOW, <Shift><Opt>e produces GDK_KEY_acute. I'll add to it tomorrow to invert <Shift><Opt> and <Opt>, so that <Opt> produces the dead key and <Shift><Opt> produces the plain character.
Created attachment 175439 [details] [review] Better handles deadkeys with special_ucs_table This does a better job, as one doesn't need to use the <Shift><Opt> variant for the dead key to work, and it doesn't necessarily convert combing characters into dead keys as did simply adding keyvalues to special_ucs_table. I also noticed while I was experimenting with dumping keytables that a few keys on the U.S. Extended keyboard return two characters. For example, <Shift><Opt>s returns 0x00a0 0x0311. a0 is a non-breaking space, not very interesting, but 311 is a combining inverted breve (and it's supposed to be dead as well on this particular key). This patch therefore returns the last character in the string rather than the first. This patch doesn't quite match what I'm pushing into quartz-integration as that has some refactors of maybe_update_keymap to make it a bit clearer and to remove duplicated code.
Created attachment 194355 [details] [review] Adds acute/doubleacute dead keys for OSX US International layout Requires the patch from Comment 11.
I think this patch is pretty much ready for merging to master and 2-24. John, do you think Levi's patch should be included too?
(In reply to comment #13) > I think this patch is pretty much ready for merging to master and 2-24. > John, do you think Levi's patch should be included too? Yes, absolutely.
(In reply to comment #13) > I think this patch is pretty much ready for merging to master and 2-24. > John, do you think Levi's patch should be included too? I agree both patches can go in master and 2-24. Mitch tells me that in the future, this kind of handling should be moved to IM.
Fixed in both 2-24 and master: commit b71f28037fea548edd36e879d05c772656481813 Author: John Ralls <jralls@ceridwen.us> Date: Fri Sep 9 10:12:40 2011 +0200 Bug 617583 - Dead accents keys don't work in GTK+ applications on OSX Handle dead keys in special_ucs_table and have them converted by UCKeyTranslate(), so all dead key combinations can be entered. Later, this should be handled in the input method, just as it's done for X11/Win32. gdk/quartz/gdkkeys-quartz.c | 77 ++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 72 insertions(+), 5 deletions(-)
(In reply to comment #15) > (In reply to comment #13) > > I think this patch is pretty much ready for merging to master and 2-24. > > John, do you think Levi's patch should be included too? > > I agree both patches can go in master and 2-24. Mitch tells me that in the > future, this kind of handling should be moved to IM. Yes, we discussed this at length yesterday. ISTM we need to get the "standard" (i.e., ASCII) key symbols in gdkevents-quartz and move the Unicode translation to an IM. That's a pretty significant change, though, so I'd think it would be for master only. Doing that would fix the problems where (e.g) an option-d accelerator is displayed as ∂ on the menu as well as accelerator/binding behavior changing depending on the keyboard layout. Note that both those problems existed before this patch.
its an appalling hack, but i direct your attention momentarily to the function guint osx_keyval_without_alt (guint accent_keyval) which can be found here: http://viewcvs.ardour.org/index.cgi/ardour2/ardour2/branches/3.0/gtk2_ardour/utils.cc?revision=10030&view=markup in ardour on os x, we translate key events with the alt/option key pressed back into "regular" keys using this function. if you scroll down just past that function to key_press_focus_accelerator_handler (Gtk::Window& window, GdkEventKey* ev) you can see a comment that explains the use of this. its slightly complex because for accelerator purposes, we want the regular key value, but if focus is on a widget that accepts text entry, we want the alternate one. not advocating this for GTK itself, but something that might possibly be useful somewhere to think about.
Thanks, I'll have a look at that in a bit. Would moving the UCKeyTranslate call into an IM, as I described in 17, make this unnecessary?
i don't think so. my recollection is that the NSEvent contains the alternate/composite key so GDK never even sees the key corresponding to the keycap.
hmm, i think my recollection is likely wrong there. you probably know better then me. if GDK can relay <alt>-q rather than <alt>-oe then yes, it would be unnecessary.
Yes, that would be my plan. (IIRC, it doesn't relay <alt>-œ; the <alt> gets eaten and it just returns the œ.)