Re: [ibus-user] Switching between japanese and a custom input method

[Ma Xiaojun]

ibus-daemon --version

Also, would ibus-m17n work for you?

[Vivien Hayazaki]

On Wednesday, 7 November 2012 17:16:42 UTC-2, Ma Xiaojun wrote:

ibus-daemon --version

Also, would ibus-m17n work for you?

 ibus-daemon - Version 1.4.99.20121006

I installed ibus-m17n here and it seems that it only applies to Japanese and other non-latin scripts. Since the Japanese input with Anthy is working flawlessly (even allowing me to use the dvorak layout), I don't think it helps, unfortunately.

What I need is to have iBus allow me to switch between the Japanese input with Anthy (which is working fine) and the system's "default" layout as specified in the Xorg config file.

I don't know if this is a bug or how it is supposed to be. Usually I'd just setup the Japanese input and ctrl-space would switch between that and the system default layout. For some
reason that no longer works and if I only set the Japanese input in ibus, that's all I can type in.

[Ma Xiaojun]

What do you think?

[Takao Fujiwara]

ibus 1.5 needs to specify the keyboard layout for the ibus engines.
Which ibus-anthy do you use?
The ibus-anthy decides the default layout in the build time with
'./configure --with-layout=jp'.
If you could specify the --with-layout=default, probably the system
layout can be used.
Also the latest ibus-anthy provides to customize the layout with
ibus-setup-anthy.

> --
> You received this message because you are subscribed to the Google
> Groups "ibus-user" group.
> iBus project web page: http://code.google.com/p/ibus/
> iBus project group: http://groups.google.com/group/ibus-user?hl=en

[Vivien Hayazaki]

I'm on ibus-anthy 1.4.99.20121006-1.
Although there's no "ibus-setup-anthy" command, when I open ibus settings, I can go to Anthy settings and customize what layout ibus-anthy should use.

My problem is that no other input method lets me do that, so I'm stuck with switching between Japanese (which is working fine with my dvorak-br layout) and
other input methods that force me to use either qwerty or pure dvorak (which doesn't work for me, I need dvorak-br because I type a lot of Brazilian Portuguese)

[fujiwara]

On Saturday, November 10, 2012 5:28:24 PM UTC+9, Vivien Hayazaki wrote:

I'm on ibus-anthy 1.4.99.20121006-1.
Although there's no "ibus-setup-anthy" command, when I open ibus settings, I can go to Anthy settings and customize what layout ibus-anthy should use.

Yes, ibus-setup can launch ibus-setup-anthy. Probably you could confirm it with 'ps' command.
 

My problem is that no other input method lets me do that, so I'm stuck with switching between Japanese (which is working fine with my dvorak-br layout) and
other input methods that force me to use either qwerty or pure dvorak (which doesn't work for me, I need dvorak-br because I type a lot of Brazilian Portuguese)

Do you mean you need to switch ibus keyboard engine of br(dvorak) and and ibus anthy engine (the layout is determined by ibus-setup-anthy)?
Currently br(dvorak) is not available in ibus-setup as I forgot to upstream a patch:
https://github.com/ibus/ibus/blob/master/engine/simple.xml.in.in

Probably you could add the following entry in /usr/share/ibus/component/simple.xml direclty and restart ibus-daemon:

		<engine>
			<name>xkb:br:dvorak:por</name>
			<language>por</language>
			<license>GPL</license>
			<author>Peng Huang &lt;shawn....@gmail.com&gt;</author>
			<layout>br</layout>
			<layout_variant>dvorak</layout_variant>
			<longname>Portuguese (Brazil) (dvorak)</longname>
			<description>Portuguese (Brazil) (dvorak)</description>
                        <icon>ibus-keyboard</icon>
			<rank>99</rank>
		</engine>

Then "Input Method" tab in ibus-setup will show the br(dvorak) engine.

 The latest ibus supports the "<layout_variant>" tag:
https://github.com/ibus/ibus/commit/afdb7f6c33fda44c2ad4054b7c23523d59218f47

[Vivien Hayazaki]

Thanks a lot!

I installed ibus from git, modified the file according to what you showed me, and now it works!

However, there's another issue. It's not ibus fault, but it seems that ibus overrides the previous fixes.

Typing <´> + <c> should give me a c with cedilla, <ç>. Instead it gives me <ć>.

More information on why that is (and how to fix it) can be seen here:
http://unix.stackexchange.com/questions/7493/why-is-the-us-international-keyboard-layout-on-debian-different
and here (rather more long winded):
http://my.opera.com/CrazyTerabyte/blog/2010/11/04/how-x11-xcompose-works

The previous fix of editing /usr/share/X11/locale/en_US.UTF-8/Compose no longer works.
When I start the Xfce session without ibus, the cedilla still works, so it seems ibus is overriding something,
or ibus doesn't look at the compose file for this definition.

 <ć> is not used in Portuguese, and <ç> is used extensively, so if there's a way to make ibus just do the right thing when you choose Portuguese input with the Dvorak-br layout variant,
this would mean the end to ALL my troubles ever (plus other people's with similar configurations).

If there's no way to workaround this in ibus itself, could you guys at least point me in the right direction?

On Saturday, 10 November 2012 09:48:39 UTC-2, fujiwara wrote:

On Saturday, November 10, 2012 5:28:24 PM UTC+9, Vivien Hayazaki wrote:

I'm on ibus-anthy 1.4.99.20121006-1.
Although there's no "ibus-setup-anthy" command, when I open ibus settings, I can go to Anthy settings and customize what layout ibus-anthy should use.

Yes, ibus-setup can launch ibus-setup-anthy. Probably you could confirm it with 'ps' command.
 

My problem is that no other input method lets me do that, so I'm stuck with switching between Japanese (which is working fine with my dvorak-br layout) and
other input methods that force me to use either qwerty or pure dvorak (which doesn't work for me, I need dvorak-br because I type a lot of Brazilian Portuguese)

Do you mean you need to switch ibus keyboard engine of br(dvorak) and and ibus anthy engine (the layout is determined by ibus-setup-anthy)?
Currently br(dvorak) is not available in ibus-setup as I forgot to upstream a patch:
https://github.com/ibus/ibus/blob/master/engine/simple.xml.in.in

Probably you could add the following entry in /usr/share/ibus/component/simple.xml direclty and restart ibus-daemon:

		<engine>
			<name>xkb:br:dvorak:por</name>
			<language>por</language>
			<license>GPL</license>

			<author>Peng Huang &lt;shawn...@gmail.com&gt;</author>

[Takao Fujiwara]

On (11/10/2012 10:26 PM), Vivien Hayazaki-san wrote:
> Thanks a lot!
>
> I installed ibus from git, modified the file according to what you
> showed me, and now it works!
>
> However, there's another issue. It's not ibus fault, but it seems that
> ibus overrides the previous fixes.
>
> Typing <´> + <c> should give me a c with cedilla, <ç>. Instead it gives
> me <ć>.

Ah, I forgot to backport that patch too. ibus 1.4 had used the cedilla
map when locale is pt_BR* but the patch was missed in ibus 1.5:
https://github.com/fujiwarat/ibus-xkb/commit/5a122df7d15842cfaafb349d7859a7b76d41f928

Probably it's good for you to file new bugs in ibus about br(dvorak) and
cedilla map for ibus 1.5

At the moment, you could use the cedilla map If you could modify the
ibus/src/gtkimcontextsimpleseqs.h directly and rebuild the ibus package.

--- ibus/src/gtkimcontextsimpleseqs.h.orig
+++ ibus/src/gtkimcontextsimpleseqs.h
@@ -1327,7 +1327,7 @@ IBUS_KEY_apostrophe, IBUS_KEY_comma, 0x2
IBUS_KEY_apostrophe, IBUS_KEY_less, 0x2018,
IBUS_KEY_apostrophe, IBUS_KEY_greater, 0x2019,
IBUS_KEY_apostrophe, IBUS_KEY_A, 0x00C1,
-IBUS_KEY_apostrophe, IBUS_KEY_C, 0x0106,
+IBUS_KEY_apostrophe, IBUS_KEY_C, 0x00C7,
IBUS_KEY_apostrophe, IBUS_KEY_E, 0x00C9,
IBUS_KEY_apostrophe, IBUS_KEY_G, 0x01F4,
IBUS_KEY_apostrophe, IBUS_KEY_I, 0x00CD,
@@ -1344,7 +1344,7 @@ IBUS_KEY_apostrophe, IBUS_KEY_W, 0x1E82,
IBUS_KEY_apostrophe, IBUS_KEY_Y, 0x00DD,
IBUS_KEY_apostrophe, IBUS_KEY_Z, 0x0179,
IBUS_KEY_apostrophe, IBUS_KEY_a, 0x00E1,
-IBUS_KEY_apostrophe, IBUS_KEY_c, 0x0107,
+IBUS_KEY_apostrophe, IBUS_KEY_c, 0x00E7,
IBUS_KEY_apostrophe, IBUS_KEY_e, 0x00E9,
IBUS_KEY_apostrophe, IBUS_KEY_g, 0x01F5,
IBUS_KEY_apostrophe, IBUS_KEY_i, 0x00ED,
@@ -1782,7 +1782,7 @@ IBUS_KEY_A, IBUS_KEY_asciitilde, 0x00C3,
IBUS_KEY_A, IBUS_KEY_diaeresis, 0x00C4,
IBUS_KEY_A, IBUS_KEY_acute, 0x00C1,
IBUS_KEY_B, IBUS_KEY_period, 0x1E02,
-IBUS_KEY_C, IBUS_KEY_apostrophe, 0x0106,
+IBUS_KEY_C, IBUS_KEY_apostrophe, 0x00C7,
IBUS_KEY_C, IBUS_KEY_comma, 0x00C7,
IBUS_KEY_C, IBUS_KEY_period, 0x010A,
IBUS_KEY_C, IBUS_KEY_slash, 0x20A1,
@@ -2238,7 +2238,7 @@ IBUS_KEY_b, IBUS_KEY_Greek_iota, 0x1FD0,
IBUS_KEY_b, IBUS_KEY_Greek_upsilon, 0x1FE0,
IBUS_KEY_b, 0x1EA0, 0x1EB6,
IBUS_KEY_b, 0x1EA1, 0x1EB7,
-IBUS_KEY_c, IBUS_KEY_apostrophe, 0x0107,
+IBUS_KEY_c, IBUS_KEY_apostrophe, 0x00E7,
IBUS_KEY_c, IBUS_KEY_comma, 0x00E7,
IBUS_KEY_c, IBUS_KEY_period, 0x010B,
IBUS_KEY_c, IBUS_KEY_slash, 0x00A2,
@@ -2540,7 +2540,7 @@ IBUS_KEY_macron, 0x1E37, 0x1E39,
IBUS_KEY_macron, 0x1E5A, 0x1E5C,
IBUS_KEY_macron, 0x1E5B, 0x1E5D,
IBUS_KEY_acute, IBUS_KEY_A, 0x00C1,
-IBUS_KEY_acute, IBUS_KEY_C, 0x0106,
+IBUS_KEY_acute, IBUS_KEY_C, 0x00C7,
IBUS_KEY_acute, IBUS_KEY_E, 0x00C9,
IBUS_KEY_acute, IBUS_KEY_G, 0x01F4,
IBUS_KEY_acute, IBUS_KEY_I, 0x00CD,
@@ -2557,7 +2557,7 @@ IBUS_KEY_acute, IBUS_KEY_W, 0x1E82,
IBUS_KEY_acute, IBUS_KEY_Y, 0x00DD,
IBUS_KEY_acute, IBUS_KEY_Z, 0x0179,
IBUS_KEY_acute, IBUS_KEY_a, 0x00E1,
-IBUS_KEY_acute, IBUS_KEY_c, 0x0107,
+IBUS_KEY_acute, IBUS_KEY_c, 0x00E7,
IBUS_KEY_acute, IBUS_KEY_e, 0x00E9,
IBUS_KEY_acute, IBUS_KEY_g, 0x01F5,
IBUS_KEY_acute, IBUS_KEY_i, 0x00ED,

> <author>Peng Huang &lt;shawn...@gmail.com <javascript:>&gt;</author>

> <http://groups.google.com/group/ibus-user?hl=en>

[Vivien Hayazaki]

I wasn't able to try recompiling at the time so I just let this issue lie for a while.

But now I have the time again and I went back to this.

I did edit ibus/src/gtkimcontextsimpleseqs.h and rebuilt ibus from the modified source, and the issue still persists.

I should also note that I'm using a japanese UTF-8 locale, not a pt_BR one, so if the cedilla map depends on
a pt locale, that's probably why editing it and rebuilding did not work for me.

I also filed a bug here: http://code.google.com/p/ibus/issues/detail?id=1644