Bug 917130 - [pt_BR] Keyboard loses dead keys on login
[pt_BR] Keyboard loses dead keys on login
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
: i18n, Reopened
: 918740 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-01 14:52 EST by Gustavo Maciel Dias Vieira
Modified: 2014-01-15 01:32 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-15 01:32:55 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
$HOME/.cache/imsettings/log with imsettings-1.5.0-2.fc18 (1.42 KB, text/plain)
2013-03-12 08:14 EDT, Gustavo Maciel Dias Vieira
no flags Details
$HOME/.cache/imsettings/log with imsettings-1.5.1-2.fc18 (1.76 KB, text/plain)
2013-03-12 08:15 EDT, Gustavo Maciel Dias Vieira
no flags Details
first-login-after-default-install-in-brasilian-portuguese.ogv (4.87 MB, application/octet-stream)
2013-03-12 17:43 EDT, Mike FABIAN
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 695867 None None None Never

  None (edit)
Description Gustavo Maciel Dias Vieira 2013-03-01 14:52:10 EST
Description of problem:

If I select the Portuguese (Brazil) keyboard layout it works until the next start of session. Once a new session is started, dead keys stop working. Sometimes, the first login after a reboot works, sometimes not.


Version-Release number of selected component (if applicable):

I don't know which component is responsible. Here's my guess: 
gnome-session-3.6.2-3.fc18.x86_64
systemd-197-1.fc18.2.x86_64

How reproducible:
Deterministic after first login.


Steps to Reproduce:
1. Select the Portuguese (Brazil) keyboard layout and set it as default
2. End session
3. Start a new session.
  
Actual results:
Dead keys gone: ~a

Expected results:
Dead keys working: ã

Additional info:

This problem might affect all dead keys layouts. See: http://forums.fedoraforum.org/showthread.php?t=288410

When a layout is first activated it works. This fact leads to the workaround: install another layout and change to it and back again.
Comment 1 Gustavo Maciel Dias Vieira 2013-03-06 13:33:52 EST
In a new F18 installation, without any updates, the bug doesn't appear. It only appears after the first batch of updates.
Comment 2 Gustavo Maciel Dias Vieira 2013-03-06 15:30:12 EST
I've made a fresh installation of F18 and applied updates selectively. I nailed the problem to the imsettings packages:

imsettings-1.5.1-2.fc18.x86_64
imsettings-gnome-1.5.1-2.fc18.x86_64
imsettings-libs-1.5.1-2.fc18.x86_64

With the previous versions of these packages the problem disappears. Downgrade seems an acceptable workaround.

Also, maybe it is not related, but opening the GNOME control center with the most recent version takes a while sometimes and also kills Firefox and GNOME terminal. It is not deterministic, but I wasn't able to reproduce it with imsettings-1.5.0-2
Comment 3 Akira TAGOH 2013-03-06 23:06:21 EST
imsettings isn't responsible to setup XKB and no longer take any actions on GNOME3 because of IBus integration. you should check your input source configuration on control-center.
Comment 4 Gustavo Maciel Dias Vieira 2013-03-07 07:37:06 EST
I see, but sometimes software interactions are subtle and seem to defy logic. But, surely you are well aware of that.

For instance, I've tested and discovered that the bug does not show if the locale is set to en_US. But, it is present if the locale is pt_BR. I suspect en_US receives especial treatment and makes bugs like this pretty hard to reproduce by most developers.

Also, there are a bunch of SELinux AVCs when using an updated selinux-policy. But, these are unrelated to this problem, as the bug is reproducible using a fresh install as base. To make testing easier it is best not to update selinux-policy.

So, I'd like to stress the info on comment #2 and register detailed instructions to reproduce the bug:
 * Make fresh install of F18 and apply no updates.
 * Select the pt_BR locale.
 * Install a keyboard layout with dead keys. As a Brazilian keyboard isn't common, I'd suggest "English (US, international with dead keys)". At this point the bug isn't present in no form whatsoever.
 * Update only the listed imsettings packages (1.5.1-2.fc18), reboot and the bug appears in a deterministic way.
 * To confirm, downgrade the imsettings update and the bug disappears.

Just to make it clear, all changes listed above were made exclusively using the GNOME control-center.
Comment 5 Akira TAGOH 2013-03-08 00:18:06 EST
That looks like you are missing gtk*-immodule-xim package maybe. or even if you downgrade imsettings and works similarly on GTK+ apps and pure-X apps, I can get rid of pt_BR to enforce xcompose though. see Bug#505100 for more details before suggesting that however.
Comment 6 Gustavo Maciel Dias Vieira 2013-03-08 12:27:41 EST
Both immodule-xim packages are present. Upgrading these packages (and GTK with them) changes nothing. Versions present:

gtk2-immodule-xim-2.24.13-1.fc18.x86_64
gtk3-immodule-xim-3.6.2-1.fc18.x86_64

Regarding GTK x X apps, good catch! If xterm is a pure-X app, them it *works* with pure-X apps. I get ~a in gnome-terminal and ã in xterm.

I read bug #505100. I can't really say I understand its relation to this bug, but I discovered some very interesting info:

 * When the bug is present Ctrl-Shift-u unicode input in GTK is broken.
 * When the bug isn't present Ctrl-Shift-u unicode input works and acute+c gives ć in gnome-terminal, while it gives ç in xterm.

So, the conclusion is that the solution to bug #505100 is somehow causing this bug. That is, when a login session starts wherever that was done to fix #505100 kicks in and screws dead keys. If I select a layout, dead keys start working but no ç only ć. So, ha ha ha, it is pt_BR that is receiving especial treatment. Sorry.

The question is, why is this being triggered by the new version of imsettings packages (1.5.1-2.fc18)? Let's do more experiments. If I revert imsettings to 1.5.0-2 I get: 

 * Ctrl-Shift-u unicode input works and acute+c gives ć in gnome-terminal, while it gives ç in xterm.

So, somehow, imsettings-1.5.1-2 restores the fix to bug #505100, meanwhile breaking dead keys in the process. Sweet.

Expect a legion of pt_BR mad users demanding a pound of flesh of the first scapegoat available. :)

Akira, please ask if you need any other info.
Comment 7 Akira TAGOH 2013-03-10 23:15:30 EDT
please check what value org.gnome.desktop.interface.gtk-im-module has. that should be only difference between them:

$ gsettings get org.gnome.desktop.interface gtk-im-module
Comment 8 Akira TAGOH 2013-03-10 23:18:05 EDT
and $GTK_IM_MODULE too
Comment 9 Jens Petersen 2013-03-11 05:34:26 EDT
Fujiwara pointed that gnome seems to assume gtk-im-context-simple now.

https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/keyboard/gsd-keyboard-manager.c#n1029
Comment 10 Rui Matos 2013-03-11 05:59:05 EDT
I'd like to see to the output of:

$ gsettings list-recursively org.gnome.desktop.input-sources

Thanks
Comment 11 Gustavo Maciel Dias Vieira 2013-03-11 09:08:24 EDT
Just after login, with the bug present, the output is:

[teste@localhost ~]$ gsettings get org.gnome.desktop.interface gtk-im-module
'xim:xim'
[teste@localhost ~]$ echo $GTK_IM_MODULE

[teste@localhost ~]$ gsettings list-recursively org.gnome.desktop.input-sources
org.gnome.desktop.input-sources current uint32 0
org.gnome.desktop.input-sources show-all-sources false
org.gnome.desktop.input-sources sources [('xkb', 'br'), ('xkb', 'us+intl')]
org.gnome.desktop.input-sources xkb-options @as []


If I select a keyboard layout to work around the bug, the output is:

[teste@localhost ~]$ gsettings get org.gnome.desktop.interface gtk-im-module
'gtk-im-context-simple'
[teste@localhost ~]$ echo $GTK_IM_MODULE

[teste@localhost ~]$ gsettings list-recursively org.gnome.desktop.input-sources
org.gnome.desktop.input-sources current uint32 0
org.gnome.desktop.input-sources show-all-sources false
org.gnome.desktop.input-sources sources [('xkb', 'br'), ('xkb', 'us+intl')]
org.gnome.desktop.input-sources xkb-options @as []
Comment 12 Gustavo Maciel Dias Vieira 2013-03-11 09:20:13 EDT
If I downgrade imsettings I get:

[teste@localhost ~]$ gsettings get org.gnome.desktop.interface gtk-im-module
'gtk-im-context-simple'
[teste@localhost ~]$ echo $GTK_IM_MODULE

[teste@localhost ~]$ gsettings list-recursively org.gnome.desktop.input-sources
org.gnome.desktop.input-sources current uint32 0
org.gnome.desktop.input-sources show-all-sources false
org.gnome.desktop.input-sources sources [('xkb', 'br'), ('xkb', 'us+intl')]
org.gnome.desktop.input-sources xkb-options @as []
Comment 13 Rui Matos 2013-03-11 10:11:32 EDT
(In reply to comment #11)
> Just after login, with the bug present, the output is:
> 
> [teste@localhost ~]$ gsettings get org.gnome.desktop.interface gtk-im-module
> 'xim:xim'

This shouldn't ever happen in gnome and g-s-d certainly makes sure to set it to either 'gtk-im-context-simple' or 'ibus'. Not sure what's going on here. Is this a regular gnome session?
Comment 14 Gustavo Maciel Dias Vieira 2013-03-11 10:50:05 EDT
Yes, it is a regular session.

The trigger for this bug is the upgrade from imsettings-1.5.0-2 to imsettings-1.5.1-2. The changes between these versions may give you a clue.

By the way, when things started to get hairy, I started to do all my testing on a VM, using a default account, with no customizations at all. See comment #4. You may want to recreate such setup and reproduce the issue locally.
Comment 15 Akira TAGOH 2013-03-12 00:26:57 EDT
(In reply to comment #13)
> (In reply to comment #11)
> > Just after login, with the bug present, the output is:
> > 
> > [teste@localhost ~]$ gsettings get org.gnome.desktop.interface gtk-im-module
> > 'xim:xim'
> 
> This shouldn't ever happen in gnome and g-s-d certainly makes sure to set it
> to either 'gtk-im-context-simple' or 'ibus'. Not sure what's going on here.
> Is this a regular gnome session?

This is because xcompose.conf doesn't restrict applying it on even GNOME3. weird thing would be rather it gives different behavior compared to xterm say. it is supposed to behave same.

How about explicitly set GTK_IM_MODULE=xim and run applications? if it works too and behave same with xterm, it's not what I should fix in imsettings.
Comment 16 Jens Petersen 2013-03-12 05:20:24 EDT
I reproduced here in *xterm* running in pt_BR GNOME with br keyboard layout:

- in Fedora-18-x86_64-Live-Desktop.iso (imsettings-1.5.0-2.fc18)
  I can input c_cedilla with 'c

- with F18-x86_64-LIVE-DESK-20130228.iso (imsettings-1.5.1-2.fc18)
  I cannot input c_cedilla with 'c

in neither case does it work in gtk apps, which is probably comment 9.


# ("'" deadkey is right of P on br layout.)
Comment 17 Akira TAGOH 2013-03-12 05:53:06 EDT
hmm, I should make more clearer earlier. please attach $HOME/.cache/imsettings/log. that would helps to understand what happened there.
Comment 18 Jens Petersen 2013-03-12 06:18:52 EDT
Anyway, Gustavo, I guess you are using "us(intl)" layout, right?
Comment 19 Akira TAGOH 2013-03-12 06:20:11 EDT
Anyway, if I run xterm or gedit with LANG=pt_BR.UTF-8 XMODIFIERS=@im=none GTK_IM_MODULE=xim and ('xkb','br') in input sources, I can get ć with `c and ã with ~a on both. I don't see any wrong there.
Comment 20 Gustavo Maciel Dias Vieira 2013-03-12 08:11:28 EDT
(In reply to comment #15)
> 
> How about explicitly set GTK_IM_MODULE=xim and run applications? if it works
> too and behave same with xterm, it's not what I should fix in imsettings.

If I set GTK_IM_MODULE=xim there is no difference, the bug remains.
Comment 21 Gustavo Maciel Dias Vieira 2013-03-12 08:14:51 EDT
Created attachment 708928 [details]
$HOME/.cache/imsettings/log with imsettings-1.5.0-2.fc18
Comment 22 Gustavo Maciel Dias Vieira 2013-03-12 08:15:43 EDT
Created attachment 708929 [details]
$HOME/.cache/imsettings/log with imsettings-1.5.1-2.fc18
Comment 23 Gustavo Maciel Dias Vieira 2013-03-12 08:17:09 EDT
(In reply to comment #17)
> hmm, I should make more clearer earlier. please attach
> $HOME/.cache/imsettings/log. that would helps to understand what happened
> there.

I've attached the log files with both versions of imsettings.
Comment 24 Gustavo Maciel Dias Vieira 2013-03-12 08:22:12 EDT
(In reply to comment #18)
> Anyway, Gustavo, I guess you are using "us(intl)" layout, right?

No, I'm using the br layout ("Portuguese (Brazil)" in control-center).

I'm not affected by the cedilla problem and only mentioned it as new evidence, relating to bug #505100.
Comment 25 Mike FABIAN 2013-03-12 09:15:16 EDT
(In reply to comment #4)
> So, I'd like to stress the info on comment #2 and register detailed
> instructions to reproduce the bug:
>  * Make fresh install of F18 and apply no updates.
>  * Select the pt_BR locale.

Did you do the install in pt_BR locale?

Did you select the make the keyboard for the selected language
the default at the first screen of installation?
Comment 26 Gustavo Maciel Dias Vieira 2013-03-12 09:23:19 EDT
(In reply to comment #25)
> (In reply to comment #4)
> > So, I'd like to stress the info on comment #2 and register detailed
> > instructions to reproduce the bug:
> >  * Make fresh install of F18 and apply no updates.
> >  * Select the pt_BR locale.
> 
> Did you do the install in pt_BR locale?

No at first, because anaconda in pt_BR hides some dialogs making it almost impossible to use. My first installation was in en_US later changed to pt_BR. I suspected that might be the cause, so I made other installation (in a VM, to be able to accept all anaconda defaults) in pt_BR. Got the same result with both.

> 
> Did you select the make the keyboard for the selected language
> the default at the first screen of installation?

In both situations above I selected the "Portuguese (Brazil)" layout during installation and made it default.
Comment 27 Mike FABIAN 2013-03-12 12:24:31 EDT
Difference in the ~/.cache/imsettings/log between
imsettings-1.5.0-2 and imsettings-1.5.1-2:

[mfabian@localhost ~]$ diff  -u imsettings-log-1.5.0.2 imsettings-log-1.5.1-2 
--- imsettings-log-1.5.0.2	2013-03-12 14:03:08.927546408 -0200
+++ imsettings-log-1.5.1-2	2013-03-12 14:02:50.919777478 -0200
@@ -1,23 +1,23 @@
-[ 1363103359.670799]: IMSettings-Daemon[10514]: INFO: Starting imsettings-daemon...
-[ 1363103359.671036]: IMSettings-Daemon[10514]: INFO:   [HOME=/home/mfabian/.config/imsettings]
-[ 1363103359.671091]: IMSettings-Daemon[10514]: INFO:   [XINPUTRCDIR=/etc/X11/xinit/]
-[ 1363103359.671141]: IMSettings-Daemon[10514]: INFO:   [XINPUTDIR=/etc/X11/xinit/xinput.d/]
+[ 1363100244.497828]: IMSettings-Daemon[5461]: INFO: Starting imsettings-daemon...
+[ 1363100244.498026]: IMSettings-Daemon[5461]: INFO:   [HOME=/home/mfabian/.config/imsettings]
+[ 1363100244.498079]: IMSettings-Daemon[5461]: INFO:   [XINPUTRCDIR=/etc/X11/xinit/]
+[ 1363100244.498126]: IMSettings-Daemon[5461]: INFO:   [XINPUTDIR=/etc/X11/xinit/xinput.d/]
 
-[ 1363103359.671189]: IMSettings-Daemon[10514]: INFO:   [MODULEDIR=/usr/lib64/imsettings]
+[ 1363100244.498202]: IMSettings-Daemon[5461]: INFO:   [MODULEDIR=/usr/lib64/imsettings]
 
-[ 1363103359.671243]: IMSettings-Daemon[10514]: INFO:   [MODULES=gsettings]
+[ 1363100244.498263]: IMSettings-Daemon[5461]: INFO:   [MODULES=gsettings]
 
 imsettings information
 ==========================
 XINPUTRC: /etc/X11/xinit/xinput.d//xcompose.conf
 	  File: "/etc/X11/xinit/xinput.d//xcompose.conf"
 	  Size: 146       	Blocks: 8          IO Block: 4096   arquivo comum
-	Device: fd01h/64769d	Inode: 1189563     Links: 1
+	Device: fd01h/64769d	Inode: 1189564     Links: 1
 	Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
 	Context: system_u:object_r:bin_t:s0
-	Access: 2013-03-12 13:49:19.379551431 -0200
-	Modify: 2013-03-12 13:13:58.000000000 -0200
-	Change: 2013-03-12 13:48:46.760166169 -0200
+	Access: 2013-03-12 12:14:38.676679875 -0200
+	Modify: 2012-12-20 03:59:00.000000000 -0200
+	Change: 2013-03-12 12:05:09.260406833 -0200
 	 Birth: -
 Is DBus enabled: yes
 Is imsettings enabled: yes
@@ -27,10 +27,13 @@
 GUESS_DESKTOP: $GDMSESSION
 DISABLE_IMSETTINGS: 
 IMSETTINGS_DISABLE_DESKTOP_CHECK: 
-DBUS_SESSION_BUS_ADDRESS: unix:abstract=/tmp/dbus-JwlmGoiXph,guid=e7002729a7bd683adc462e3c513f4e7f
+DBUS_SESSION_BUS_ADDRESS: unix:abstract=/tmp/dbus-66dxjGy2Jh,guid=4401facef6b1c4a7ab312c94513f4254
 GTK_IM_MODULE: 
 QT_IM_MODULE: xim
 XMODIFIERS: @im=none
 IMSETTINGS_MODULE: X compose table
 IMSETTINGS_INTEGRATE_DESKTOP: yes
 
+[ 1363100247.372105]: IMSettings-Daemon[5461]: INFO: Attempting to switch IM to X compose table [lang=pt_BR.UTF-8, update=false]
+[ 1363100248.203136]: IMSettings-Daemon[5461]: INFO:   no need to invoke any auxiliary process for X compose table
+[ 1363100248.203469]: IMSettings-GSettings backend[5461]: INFO: Setting up xim:xim as gtk+ immodule
[mfabian@localhost ~]$
Comment 28 Mike FABIAN 2013-03-12 13:38:45 EDT
To demonstrate what happens:

- set the “Portuguese (Brasil)” keyboard in the panel.
- Start some other, non-GTK terminal, like xterm.
- killall gnome-terminal
  to make sure gnome-terminal is really gone.
  (gnome-terminal uses one process for multiple windows, i.e. if you
  start "gnome-terminal" from a gnome-terminal, you only get a new
  window for the same process, not a new gnome-terminal).

- Now start a gnome-terminal like this from the xterm:

  env XMODIFIERS=@im=none GTK_IM_MODULE=xim LANG=pt_BR.UTF-8 gnome-terminal

  Now all dead keys work correctly, including ç (ç is typed by typing
  the key to the right of ‘P’ followed by ‘c’)

  It is important to use XMODIFIERS=@im=none *not* XMODIFIERS=@im=ibus !

  If you use XMODIFIERS=@im=ibus and ibus is running, you will get ć,
  not a ç (when using the dead key to the right of P)
  
  If you use XMODIFIERS=@im=ibus and ibus is *not* running, you will
  get the broken behaviour where the dead keys do not work at all.

  That is what Gustavo saw because in the default Portuguese (Brasil)
  install, ibus is not running.

  Even if ibus is not running, XMODIFIERS=@im=ibus GTK_IM_MODULE=xim
  breaks something for gnome-terminal.

  Contrary to gnome-terminal, xterm doesn't seem to care whether you
  use XMODIFIERS=@im=none or XMODIFIERS=@im=ibus if ibus is *not*
  running.
  
  *If* ibus is running, xterm *does* care because then it uses ibus
  with XMODIFIERS=@im=ibus, i.e. typing the key to the right of ‘P’
  followed by ‘c’ will give ć.  But whether ibus is running or not,
  xterm it uses X deadkey support for Portugese if started with
  XMODIFIERS=@im=none

  So xterm will use X deadkey support for XMODIFIERS=@im=whatever as
  long as there is no XIM input server named "whatever" running.

  I.e. as far as xterm is concerned, XMODIFIERS=@im=none and
  XMODIFIERS=@im=whatever behave the same as long as there is no input
  server named "whatever" running.
  

  For gnome-terminal however, XMODIFIERS=@im=none seems to have a
  special meaning, together with GTK_IM_MODULE=xim it uses X deadkey
  support.
  
  Any other value except "none" will try to use an XIM input server
  with that name.
  
  If such an input server is running, you will get the deadkey
  handling of that input server (probably not perfect for Portuguese),
  if no such input server is running, it is completely broken and the
  deadkeys are inserted immediately.

So perfect behaviour for Portuguese (Brasil) keyboard can be achieved
if the session is started with

  XMODIFIERS=@im=none GTK_IM_MODULE=xim LANG=pt_BR.UTF-8

Looking last part of the diff in the imsettings log in:

https://bugzilla.redhat.com/show_bug.cgi?id=917130#c27

I have the impression this is what imsettings tried to do.

I see

   XMODIFIERS: @im=none

there  and

  +[ 1363100247.372105]: IMSettings-Daemon[5461]: INFO: Attempting to switch IM to X compose table [lang=pt_BR.UTF-8, update=false]
  +[ 1363100248.203136]: IMSettings-Daemon[5461]: INFO:   no need to invoke any auxiliary process for X compose table
  +[ 1363100248.203469]: IMSettings-GSettings backend[5461]: INFO: Setting up xim:xim as gtk+ immodule

But nevertheless, after logging in, checking in gnome-terminal
shows XMODIFIERS=@im=ibus

So this together with using XIM in gnome-terminal gives the broken
deadkey support.

Now switching the keyboard in the panel from Portuguese (Brazil) to English
and back does not change the value of XMODIFIERS for gnome-terminal,
for for some reason it changes the input-module to “simple”.

So before switching the keyboard layout back and forth after the login,
right-mouse click and checking the "Input method" menu in gnome-terminal
shows "X Input Method". After switching the  keyboard layout to English
and back to Portuguese in the panel, and checking again in gnome-terminal
with right-mouse click, one  can see this  has changed to "simple".

Which appears to make the deadkeys work, but of course not perfect for
Portuguese. ã is inserted correctly, but typing the  key to the right of  ‘P’
followed by c inserts a ć, not a ç.
Comment 29 Mike FABIAN 2013-03-12 17:15:11 EDT
*** Bug 918740 has been marked as a duplicate of this bug. ***
Comment 30 Mike FABIAN 2013-03-12 17:43:40 EDT
Created attachment 709181 [details]
first-login-after-default-install-in-brasilian-portuguese.ogv

Video showing the problem when logging  into a Portuguese Gnome session
with Portuguese (Brasil) keyboard layout with deadkeys.

ibus is not running but XMODIFIERS=@im=ibus is set.

First GTK_IM_MODULE=xim is used in gnome-terminal, as ibus
is not running  this breaks deadkeys completely.

Switching the keyboard layout to English and back to Portuguese
switches gnome-terminal to use GTK_IM_MODULE=simple  which 
makes  dead keys work, although not correct for Portuguese locale.
Comment 31 Akira TAGOH 2013-03-12 23:27:28 EDT
I see gnome-settings-daemon configures XMODIFIERS=@im=ibus. we need to use XKB (via XIM) for certain languages instead of gtk-im-context-simple. reassigning.
Comment 32 Mike FABIAN 2013-03-13 03:05:08 EDT
Is gnome-settings-daemon also switching to gtk-im-context-simple
when switching the keyboard layout as in comment#30?
Comment 33 Mike FABIAN 2013-03-13 03:14:01 EDT
(In reply to comment #28)

>   If you use XMODIFIERS=@im=ibus and ibus is running, you will get ć,
>   not a ç (when using the dead key to the right of P)

Actually this depends on the locale ibus is running in. Just
learned  that from Fujiwara San, see:

https://bugzilla.redhat.com/show_bug.cgi?id=918740#c15
https://bugzilla.redhat.com/show_bug.cgi?id=918740#c16

In pt_BR.UTF-8 locale, ibus does

     dead_acute + c = ç

and in ja_JP.UTF-8 locale ibus does

     dead_acute + c = ć

So ibus does the dead key handling correctly for the locale it is running in:

mfabian@ari:~
$ grep '^<dead_acute> <c>' /usr/share/X11/locale/pt_BR.UTF-8/Compose 
<dead_acute> <c>	: "ç" ccedilla # LATIN SMALL LETTER C WITH CEDILLA
mfabian@ari:~
$ grep '^<dead_acute> <c>' /usr/share/X11/locale/en_US.UTF-8/Compose 
<dead_acute> <c>                 	: "ć"   U0107 # LATIN SMALL LETTER C WITH ACUTE
mfabian@ari:~
$
Comment 34 Akira TAGOH 2013-03-13 04:18:11 EDT
(In reply to comment #33)
> So ibus does the dead key handling correctly for the locale it is running in:
> 
> mfabian@ari:~
> $ grep '^<dead_acute> <c>' /usr/share/X11/locale/pt_BR.UTF-8/Compose 
> <dead_acute> <c>	: "ç" ccedilla # LATIN SMALL LETTER C WITH CEDILLA
> mfabian@ari:~
> $ grep '^<dead_acute> <c>' /usr/share/X11/locale/en_US.UTF-8/Compose 
> <dead_acute> <c>                 	: "ć"   U0107 # LATIN SMALL LETTER C WITH
> ACUTE
> mfabian@ari:~
> $

So another option to fix this may be to get ibus running for all of languages?
Comment 35 Mike FABIAN 2013-03-13 06:22:25 EDT
(In reply to comment #34)
> (In reply to comment #33)
> > So ibus does the dead key handling correctly for the locale it is running in:
> > 
> > mfabian@ari:~
> > $ grep '^<dead_acute> <c>' /usr/share/X11/locale/pt_BR.UTF-8/Compose 
> > <dead_acute> <c>	: "ç" ccedilla # LATIN SMALL LETTER C WITH CEDILLA
> > mfabian@ari:~
> > $ grep '^<dead_acute> <c>' /usr/share/X11/locale/en_US.UTF-8/Compose 
> > <dead_acute> <c>                 	: "ć"   U0107 # LATIN SMALL LETTER C WITH
> > ACUTE
> > mfabian@ari:~
> > $
> 
> So another option to fix this may be to get ibus running for all of
> languages?

Yes, that looks like another possibility.

By the way, how does ibus do this differently for different locales?
Does ibus use the tables in /usr/share/X11/locale/*/Compose or does it have
its own tables?
Comment 36 Rui Matos 2013-03-13 09:13:07 EDT
(In reply to comment #31)
> I see gnome-settings-daemon configures XMODIFIERS=@im=ibus. we need to use
> XKB (via XIM) for certain languages instead of gtk-im-context-simple.
> reassigning.

Akira, the original bug reported here seems to be caused by this change:

https://bitbucket.org/tagoh/imsettings/commits/2c646327cb30b30eca2571a724ede14675821506

which reverts something that we had agreed before GNOME 3.6 was released as you might remember. Apparently you reverted that because of

https://bugzilla.redhat.com/show_bug.cgi?id=887951

which I don't agree that it was a good enough to reason.
Comment 37 Mike FABIAN 2013-03-13 10:05:58 EDT
https://bugzilla.redhat.com/show_bug.cgi?id=887951

says that starting imsettings on Gnome3 is necessary when
the “ibus integration is turned off via gsettings”.

I.e. when 

$ gsettings get org.gnome.settings-daemon.plugins.keyboard active
false

So maybe imsettings should not start on Gnome when that setting
is “true”?

Would that be an acceptable solution? (For making the dead keys work
at all, not for the finer, locale specific details).
Comment 38 Mike FABIAN 2013-03-14 03:26:58 EDT
By the way, looking at:

http://unicode.org/cldr/trac/browser/trunk/keyboards/osx/pt-t-k0-osx.xml

I see in line 417 ff:

417	        <transforms type='simple'> [13年03月14日 07:38:34]
418	                <transform from="` " to="`"/>
419	                <transform from="`a" to="à"/>
420	                <transform from="`A" to="À"/>
...

So CLDR lists the way dead keys are handled together with keyboard
layouts.

I had the same feeling yesterday, it is better if the dead key
handling belongs to a keyboard layout, not to a language.

It would probably be best to change the dead key handling when the keyboard
layout is changed, maybe GTK could have several tables for this
and they could be switched when the keyboard layouts are switched.

In CLDR, neither Windows nor OSX Brasilian Portuguese keyboards
have dead_acute + c = ç though!

So maybe this dead_acute + c = ç from /usr/share/X11/locale/pt_BR.UTF-8/Compose
is really not so important.

(pt-t-k0-osx.xml is for Brasilian Portuguese and pt-PT-t-k0-osx.xml
is for European Portuguese).
Comment 39 Gustavo Maciel Dias Vieira 2013-03-14 05:38:22 EDT
After the amazing debugging work of Mike, I feel that only reverting the imsettings change won't be enough, because of bug #918740 being folded here as a duplicate. That bug is still present even when imsettings is not run (assuming this is the change difference between imsettings packages).

It appears to me that the solution for the pt_BR locale it to either start ibus by default, or go full xim:

  XMODIFIERS=@im=none GTK_IM_MODULE=xim
Comment 40 Akira TAGOH 2013-03-14 06:08:38 EDT
(In reply to comment #37)
> https://bugzilla.redhat.com/show_bug.cgi?id=887951
> 
> says that starting imsettings on Gnome3 is necessary when
> the “ibus integration is turned off via gsettings”.
> 
> I.e. when 
> 
> $ gsettings get org.gnome.settings-daemon.plugins.keyboard active
> false
> 
> So maybe imsettings should not start on Gnome when that setting
> is “true”?
> 
> Would that be an acceptable solution? (For making the dead keys work
> at all, not for the finer, locale specific details).

Well, imsettings has already enough solution. if g-s-d fix this to 1) run ibus for all languages, or 2) set xim to gtk-im-module for certain languages, I can put NOT_RUN=gnome3 to xcompose.conf, which stops applying it by imsettings.
Comment 41 Mike FABIAN 2013-03-14 07:49:23 EDT
(In reply to comment #39)
> After the amazing debugging work of Mike, I feel that only reverting the
> imsettings change won't be enough, because of bug #918740 being folded here
> as a duplicate. That bug is still present even when imsettings is not run
> (assuming this is the change difference between imsettings packages).

Ah, you are right, because when imsettings is not run for Gnome3, 
we still get XMODIFIERS=@im=ibus and as ibus is not running, this
breaks the dead keys for Emacs.

> It appears to me that the solution for the pt_BR locale it to either start
> ibus by default, or go full xim:
> 
>   XMODIFIERS=@im=none GTK_IM_MODULE=xim

Yes, either of  the two  would work.

But: Because switching keyboards in the panel changes the gtk input context to
"simple" again (same effect as GTK_IM_MODULE=simple), the handling of
the deadkeys in gnome applications (like gnome-terminal) still changes
as  soon as the keyboard layout is changed.
Comment 42 Jens Petersen 2013-03-14 21:56:12 EDT
(In reply to comment #39)
>   XMODIFIERS=@im=none GTK_IM_MODULE=xim

I don't understand how XMODIFIERS=@im=none helps?
Comment 43 Jens Petersen 2013-03-14 22:38:28 EDT
Erm, nevermind I see now.  That is just the normal X locale compose setting.

So yes.
Comment 44 Rui Matos 2013-04-02 03:57:40 EDT
This should be fixed in g-s-d 3.8.0 . Please re-open if you can still reproduce with that installed.
Comment 46 Jens Petersen 2013-04-02 04:41:02 EDT
So can we expect a fix in F19?

Can we at least keep this open until it reaches Fedora?
Comment 47 Jens Petersen 2013-04-02 04:43:17 EDT
Sorry me being silly again: in 3.8.0 so it is already in F19 pre-Alpha.

Okay we should test it then!
Comment 48 Jens Petersen 2013-09-19 02:48:21 EDT
I believe this should be fixed already in F19,
but would be good if someone could confirm.
Comment 49 Mike FABIAN 2013-09-19 09:18:02 EDT
I retested  this on Fedora 20 Alpha RC4.

- ibus is running after an installation in Brazilian Portuguese
- XMODIFIERS=@im=ibus is set
- GTK_IM_MODULE is unset

→ dead keys work!

So I think this can be considered fixed.


The language specific variants of the dead key handling
do not work though:

mfabian@ari:~
$ grep '^<dead_acute> <c>' /usr/share/X11/locale/pt_BR.UTF-8/Compose 
<dead_acute> <c>	: "ç" ccedilla # LATIN SMALL LETTER C WITH CEDILLA
mfabian@ari:~
$ grep '^<dead_acute> <c>' /usr/share/X11/locale/en_US.UTF-8/Compose 
<dead_acute> <c>                 	: "ć"   U0107 # LATIN SMALL LETTER C WITH ACUTE
mfabian@ari:~
$

I.e. it does “dead_acute + c = ç” does not work, “dead_acute + c = ć”
is always used.

Probably that is not very important though, see

https://bugzilla.redhat.com/show_bug.cgi?id=917130#c38

comment#38> In CLDR, neither Windows nor OSX Brasilian Portuguese keyboards
comment#38> have dead_acute + c = ç though!

It would be nice to have a mechanism to switch the dead
key handling together with the keyboard,
but that is probably out of the scope of this bug.

→ VERIFIED.
Comment 50 Mike FABIAN 2013-09-19 09:19:46 EDT
VERIFIED.
Comment 51 Fedora End Of Life 2013-12-21 10:52:57 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Note You need to log in before you can comment on or make changes to this bug.