GNOME Bugzilla – Bug 694427
dead_acute + c hard coded to ccedilla
Last modified: 2018-04-15 00:38:34 UTC
seems that the cases acute+c/acute+C have been hard coded to produce GDK_KEY_ccedilla/GDK_KEY_Ccedilla. gtk/gtkimcontextsimple.c, in function check_quartz_special_cases, around line 402: case GDK_KEY_dead_acute: switch (priv->compose_buffer[1]) { case 'c': value = GDK_KEY_ccedilla; break; case 'C': value = GDK_KEY_Ccedilla; break; } break; this makes it close to impossible to obtain ć and Ć, since this overrides whatever one configures in the compose tables.
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/919899
That's code for OSX, I don't know why it's an issue on Linux. Yes that mapping is totally weird, I agree, but native Mac widgets do it like that.
well, I don't know whether those lines are the ones I'm looking for. if as you say they are specific form OSX, then maybe not. even if those are not the lines responsible for the situation, on Linux we observe this: we hit in sequence <multi_key> <apostrophe> <c>, I'm now using `xev` to have a look at the generated events: they contain keycodes 66 (keysym 0xff20, Multi_key), 48 (keysym 0x27, apostrophe), 54 (keysym 0x63, c) and finally keysym 0x1000107, U0107, "ć" is produced. well, this according to `xev`. fact is: all this fine behaviour results in a ç on all our gtk programs. can you help understand?
is it possibly these two lines in the file gtkimcontextsimpleseqs.h? abca0f05 (Matthias Clasen 2011-06-10 18:36:06 -0400 782) GDK_KEY_Cacute, 0x1E08, abca0f05 (Matthias Clasen 2011-06-10 18:36:06 -0400 783) GDK_KEY_cacute, 0x1E09, do these specify something like unconditional translation of isolate GDK_KEY_Cacute and GDK_KEY_cacute into something else? the timestamp of the commit does match the report in the ubuntu community.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
(In reply to Matthias Clasen from comment #5) > We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO > if they haven't seen activity in more than a year. If this issue is still > important to you and still relevant with GTK+ 3.22 or master, please reopen > it and we will migrate it to gitlab. This issue continues annoying people that uses USA international keyboard to type '+c expecting a cedilha (like typing Portuguese language).
Luciano, I'm afraid that you have to drop your Portuguese point of view as soon as you start using the USA international keyboard. In an international setting, to get ccedilla (ç) you type <compose><,><c>, as I just did. In an international setting, next to you typing in Portuguese, there's people needing some Eastern European language, expecting <compose><acute><c> to produce ć. obviously, we're all free to define our compose rules in our own $HOME/.XCompose, which can overrule the international settings. mine has among other stuff: --------------------------------------------------------------- include "%L" <Multi_key> <n> <n> : "ñ" ntilde <Multi_key> <N> <N> : "Ñ" ntilde --------------------------------------------------------------- I had reported this bug because this was so much hard coded, that it was virtually impossible to get this Eastern European letter. BTW: is there a reason why this issue is still open?
I can - should be able to, I guess - choose the keyboard that fits my needs, and as a programmer the USA international keyboard has the best layout. And we cant change easily our laptop keyboards. Anyway, in Microsoft Windows world there's a Portuguese layout where '+c is ç, and it has been in that away since its birth - 90s. The way to get cedilla using the dead key combination '+c has typing performance reasons/purposes, instead of the odd key combinations which has serious ergometric issues. Any user, with no skills to configure a system, can set up Microsoft Windows to work in that way, just choosing the input language as Portuguese combined to the hardware you have USA international keyboard. Although, I can set up my Linux system to work in a proper way, as I want, I'll be glad to have and easier way to do it, and see my colleagues and friends not complaining that Linux world is unfriendly.
sounds like you're saying: "I suggest that <dead_acute> composed with <c> produces ccedilla — if the input language is Portuguese". this last condition is the one which would put all in agreement. from my European point of view, when I'm greeting a Polish friend, and I type "Cze<compose><'><s><compose><'><c>", and my system is not referring in any way to Portuguese, I am not particularly amused to see "Cześç" appear instead... and thinking of ergonomics, maybe it would be nice, if the input language is Spanish, to have <acute><n> produce ñ.
One thing is your current keyboard map, if your keyboard is mapped to type Polish you expect dead keys set up to speed up Polish language, not Portuguese language (Just to highlight: Portuguese might be subdivided yet in European and Brazilian). Unusual characters you can type using any kind of oddly combinations, you can even take them from a char map, is that what I do for some unusual character I have to type, when I don't want to change my keyboard layout. And the case you described is the same for all guys typing using any language but Polish, like me typing Polish using layouts like English, Portuguese, Spanish or German (these are the languages I usually type). By the way Spanish ~+n=ñ doesn't have an ergonomic issue compared to the compose key (usually ALT exactly below the comma key), and this comma is exactly the key you have to press to get the ç, so compose+,=ç Just as a reference this is the best way dead keys would work to provide a good typing (productivity) with Brazilian Portuguese language (but there are others interesting stuff regarding dead keys). It is also what any person would expect coming from Microsoft Windows: https://support.microsoft.com/en-us/help/97738/using-us-int-l-keyboard-layout-to-type-accented-characters These dead key rules (microsoft) include one more productivity approach: any other key not combinable with dead keys results in two keys, the dead key pressed + the second not-combinable key pressed, instead of only working in that way when space is pressed.
Luciano, I'm afraid I'm not making myself clear. My keyboard map has never been Polish, nor Portuguese, not even Italian. I opened this issue because, not having anything to do with Portuguese, I was completely unable to produce 'ć' except using its UTF-8 code, because some practical trick specific to Portuguese had been programmed very deep in the GTK code. do you think we can agree on my hints in comment 9? »if the input language is Portuguese« → let '+c compose to ç »otherwise« → composing '+c gives ć
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new