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.
In a new F18 installation, without any updates, the bug doesn't appear. It only appears after the first batch of updates.
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
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.
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.
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.
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.
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
and $GTK_IM_MODULE too
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
I'd like to see to the output of: $ gsettings list-recursively org.gnome.desktop.input-sources Thanks
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 []
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 []
(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?
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.
(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.
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.)
hmm, I should make more clearer earlier. please attach $HOME/.cache/imsettings/log. that would helps to understand what happened there.
Anyway, Gustavo, I guess you are using "us(intl)" layout, right?
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.
(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.
Created attachment 708928 [details] $HOME/.cache/imsettings/log with imsettings-1.5.0-2.fc18
Created attachment 708929 [details] $HOME/.cache/imsettings/log with imsettings-1.5.1-2.fc18
(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.
(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.
(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?
(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.
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 ~]$
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 ç.
*** Bug 918740 has been marked as a duplicate of this bug. ***
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.
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.
Is gnome-settings-daemon also switching to gtk-im-context-simple when switching the keyboard layout as in comment#30?
(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:~ $
(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?
(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?
(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.
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).
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).
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
(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.
(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.
(In reply to comment #39) > XMODIFIERS=@im=none GTK_IM_MODULE=xim I don't understand how XMODIFIERS=@im=none helps?
Erm, nevermind I see now. That is just the normal X locale compose setting. So yes.
This should be fixed in g-s-d 3.8.0 . Please re-open if you can still reproduce with that installed.
See https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=613f7965d15c764645085287f1dfe0b1903208b5 for the fix.
So can we expect a fix in F19? Can we at least keep this open until it reaches Fedora?
Sorry me being silly again: in 3.8.0 so it is already in F19 pre-Alpha. Okay we should test it then!
I believe this should be fixed already in F19, but would be good if someone could confirm.
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.
VERIFIED.
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.