After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 617583 - Dead accents keys don't work in GTK+ applications on OSX
Dead accents keys don't work in GTK+ applications on OSX
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Quartz
2.90.x
Other Mac OS
: Normal critical
: ---
Assigned To: gtk-quartz maintainers
gtk-bugs
Depends on:
Blocks: 613148
 
 
Reported: 2010-05-03 21:48 UTC by Javier Jardón (IRC: jjardon)
Modified: 2011-11-07 13:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add dead keys to the "special_ucs_table" (1.70 KB, patch)
2010-11-28 03:44 UTC, John Ralls
none Details | Review
Better handles deadkeys with special_ucs_table (3.43 KB, patch)
2010-11-29 00:14 UTC, John Ralls
committed Details | Review
Adds acute/doubleacute dead keys for OSX US International layout (699 bytes, patch)
2011-08-22 12:12 UTC, Levi Bard
committed Details | Review

Description Javier Jardón (IRC: jjardon) 2010-05-03 21:48:47 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)
Comment 1 Tor Lillqvist 2010-05-04 07:22:05 UTC
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.)
Comment 2 Javier Jardón (IRC: jjardon) 2010-05-04 14:40:30 UTC
Yeah Tor, you are right; ä and family work ok. I've changed the title now.
Comment 3 Kristian Rietveld 2010-05-04 20:38:58 UTC
(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.
Comment 4 Javier Jardón (IRC: jjardon) 2010-05-05 02:13:11 UTC
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).
Comment 5 Joaommp 2010-08-03 17:52:39 UTC
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.
Comment 6 Sandy Armstrong 2010-08-03 17:55:31 UTC
(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 7 Matthias Clasen 2010-08-05 00:22:35 UTC
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.
Comment 8 Joaommp 2010-08-16 03:14:43 UTC
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?
Comment 9 John Ralls 2010-11-24 00:15:41 UTC
(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?
Comment 10 John Ralls 2010-11-28 03:44:30 UTC
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.
Comment 11 John Ralls 2010-11-29 00:14:12 UTC
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.
Comment 12 Levi Bard 2011-08-22 12:12:32 UTC
Created attachment 194355 [details] [review]
Adds acute/doubleacute dead keys for OSX US International layout

Requires the patch from Comment 11.
Comment 13 Michael Natterer 2011-09-08 09:23:20 UTC
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?
Comment 14 John Ralls 2011-09-08 14:08:55 UTC
(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.
Comment 15 Kristian Rietveld 2011-09-09 07:25:15 UTC
(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.
Comment 16 Michael Natterer 2011-09-09 08:59:40 UTC
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(-)
Comment 17 John Ralls 2011-09-09 13:55:47 UTC
(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.
Comment 18 Paul Davis 2011-09-09 14:08:36 UTC
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.
Comment 19 John Ralls 2011-09-09 14:24:43 UTC
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?
Comment 20 Paul Davis 2011-09-09 14:32:47 UTC
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.
Comment 21 Paul Davis 2011-09-09 14:35:48 UTC
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.
Comment 22 John Ralls 2011-09-09 15:32:30 UTC
Yes, that would be my plan. (IIRC, it doesn't relay <alt>-œ; the <alt> gets eaten and it just returns the œ.)