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 694427 - dead_acute + c hard coded to ccedilla
dead_acute + c hard coded to ccedilla
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
unspecified
Other All
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-02-22 10:01 UTC by mariotomo
Modified: 2018-04-15 00:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description mariotomo 2013-02-22 10:01:05 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.
Comment 2 Michael Natterer 2013-02-22 18:12:39 UTC
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.
Comment 3 mariotomo 2013-02-22 18:41:30 UTC
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?
Comment 4 mariotomo 2013-02-22 18:57:16 UTC
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.
Comment 5 Matthias Clasen 2018-02-10 05:10:42 UTC
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.
Comment 6 Luciano Moreira 2018-03-23 16:31:59 UTC
(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).
Comment 7 mariotomo 2018-03-23 17:27:09 UTC
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?
Comment 8 Luciano Moreira 2018-03-23 17:50:35 UTC
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.
Comment 9 mariotomo 2018-03-23 18:53:47 UTC
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 ñ.
Comment 10 Luciano Moreira 2018-03-23 21:06:57 UTC
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.
Comment 11 mariotomo 2018-03-23 22:08:49 UTC
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 ć
Comment 12 Matthias Clasen 2018-04-15 00:38:34 UTC
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