[opensuse-m17n] update ibus to 1.5.1
hello everyone: 1.5.x stable version of ibus , ibus-pinyin , ibus-anthy and ibus-table have been released for a long time, and other ibus input engine also can work with ibus 1.5.1 ，I think we could update them in factory. Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block ibus's tray icon , we can't view which engine we use current from tray icon in ibus 1.4.2 . But in ibus 1.5.x , we can view it form the fly box while switching engine if disable ibus build for gnome-settings-daemon , or view it form gnome's language tray icon if enable ibus build for gnome-settings-daemon. What do you think? Request#150248: https://build.opensuse.org/request/show/150248 -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Tue, 29 Jan 2013 14:54:20 +0800, Hillwood Yang wrote:
hello everyone:
1.5.x stable version of ibus , ibus-pinyin , ibus-anthy and ibus-table have been released for a long time, and other ibus input engine also can work with ibus 1.5.1 ，I think we could update them in factory.
Well, now is a bad timing just before 12.3 release. We shouldn't change the devel project too much until 12.3 is released and FACTORY is opened again.
Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block ibus's tray icon , we can't view which engine we use current from tray icon in ibus 1.4.2 . But in ibus 1.5.x , we can view it form the fly box while switching engine if disable ibus build for gnome-settings-daemon , or view it form gnome's language tray icon if enable ibus build for gnome-settings-daemon.
What do you think?
Request#150248: https://build.opensuse.org/request/show/150248
The biggest problems would be the migration and the stability. When I tested ibus 1.5 shortly ago, both failed too badly. Upgrading to M17N:Devel from a system running with ibus-1.4.x (mozc, anthy and m17n) triggered frequent segfaults, even blocked the toggle of IM (likely due to key assignment / policy changes) -- in short, it was just useless on that system. Maybe we should test the upgrade paths, at least 12.3, before actually upgrading the stuff in M17N project: install 12.3-beta1 or latest one on a VM (GNOME, KDE, other DE), upgrade to M17N:Devel, and see whether any regression happens. thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Le mardi 29 janvier 2013, à 08:30 +0100, Takashi Iwai a écrit :
At Tue, 29 Jan 2013 14:54:20 +0800, Hillwood Yang wrote:
hello everyone:
1.5.x stable version of ibus , ibus-pinyin , ibus-anthy and ibus-table have been released for a long time, and other ibus input engine also can work with ibus 1.5.1 ，I think we could update them in factory.
Well, now is a bad timing just before 12.3 release. We shouldn't change the devel project too much until 12.3 is released and FACTORY is opened again.
Indeed, it's going to be hard to get a new major version in 12.3: we're in version freeze for a few weeks already, and we're past Beta. Of course, for GNOME, the new version would be better. But at this point, it's possibly too late for 12.3. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
在 2013-01-29二的 08:30 +0100，Takashi Iwai写道：
At Tue, 29 Jan 2013 14:54:20 +0800, Hillwood Yang wrote:
hello everyone:
1.5.x stable version of ibus , ibus-pinyin , ibus-anthy and ibus-table have been released for a long time, and other ibus input engine also can work with ibus 1.5.1 ，I think we could update them in factory.
Well, now is a bad timing just before 12.3 release. We shouldn't change the devel project too much until 12.3 is released and FACTORY is opened again.
Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block ibus's tray icon , we can't view which engine we use current from tray icon in ibus 1.4.2 . But in ibus 1.5.x , we can view it form the fly box while switching engine if disable ibus build for gnome-settings-daemon , or view it form gnome's language tray icon if enable ibus build for gnome-settings-daemon.
What do you think?
Request#150248: https://build.opensuse.org/request/show/150248
The biggest problems would be the migration and the stability. When I tested ibus 1.5 shortly ago, both failed too badly. Upgrading to M17N:Devel from a system running with ibus-1.4.x (mozc, anthy and m17n) triggered frequent segfaults, even blocked the toggle of IM (likely due to key assignment / policy changes) -- in short, it was just useless on that system.
I found the problem about blocked the toggle of IM only in openSUSE 12.3 (M2 and beta) after force enabled ibus-gjs 3.4.1. I don't know whether you enabled ibus-gjs too. If This is the reason about this problem , we can ignore it, end users should not install ibus-gjs 3.4.1 from M17N:Devel, and it seems that openSUSE don't supply technical support for third party repertories , especially test repertories. ibus-gjs also will not included in openSUSE 12.3 ， it only word in GNOME 3.4.x. Ibus-anthy and ibus-m17n always work fine with ibus 1.5 in my three PCs (openSUSE 12.2) and a VirtualBox system (opensuse 12.3). I can't reappear the problem about ibus-anthy and ibus-m17n which you mentioned. Can you tell me steps you how to reappear these problems which you mentioned ? I think you should test at other system , at least 12.3. To Huang Peng , Takao Fujiwara and Ma Xiaojun: Can you give us some help ?
Maybe we should test the upgrade paths, at least 12.3, before actually upgrading the stuff in M17N project: install 12.3-beta1 or latest one on a VM (GNOME, KDE, other DE), upgrade to M17N:Devel, and see whether any regression happens.
At the more that half a year, I have tested the upgrade paths (oss to M17N:Devel and M17N to M17N:Devel) at 12.2&12.3(M1,M2 and Beta) On GNOME, KDE and Mate, I didn't find any serious problem, only some minor bugs. Some of them have been fixed. If you really think there are some serious problems, can you please report them to upstream: Huang Peng , Takao Fujiwara and Ma Xiaojun ?
thanks,
Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Wed, 30 Jan 2013 13:37:18 +0800, Hillwood Yang wrote:
在 2013-01-29二的 08:30 +0100，Takashi Iwai写道：
At Tue, 29 Jan 2013 14:54:20 +0800, Hillwood Yang wrote:
hello everyone:
1.5.x stable version of ibus , ibus-pinyin , ibus-anthy and ibus-table have been released for a long time, and other ibus input engine also can work with ibus 1.5.1 ，I think we could update them in factory.
Well, now is a bad timing just before 12.3 release. We shouldn't change the devel project too much until 12.3 is released and FACTORY is opened again.
Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block ibus's tray icon , we can't view which engine we use current from tray icon in ibus 1.4.2 . But in ibus 1.5.x , we can view it form the fly box while switching engine if disable ibus build for gnome-settings-daemon , or view it form gnome's language tray icon if enable ibus build for gnome-settings-daemon.
What do you think?
Request#150248: https://build.opensuse.org/request/show/150248
The biggest problems would be the migration and the stability. When I tested ibus 1.5 shortly ago, both failed too badly. Upgrading to M17N:Devel from a system running with ibus-1.4.x (mozc, anthy and m17n) triggered frequent segfaults, even blocked the toggle of IM (likely due to key assignment / policy changes) -- in short, it was just useless on that system.
I found the problem about blocked the toggle of IM only in openSUSE 12.3 (M2 and beta) after force enabled ibus-gjs 3.4.1. I don't know whether you enabled ibus-gjs too. If This is the reason about this problem , we can ignore it, end users should not install ibus-gjs 3.4.1 from M17N:Devel, and it seems that openSUSE don't supply technical support for third party repertories , especially test repertories. ibus-gjs also will not included in openSUSE 12.3 ， it only word in GNOME 3.4.x.
Ibus-anthy and ibus-m17n always work fine with ibus 1.5 in my three PCs (openSUSE 12.2) and a VirtualBox system (opensuse 12.3). I can't reappear the problem about ibus-anthy and ibus-m17n which you mentioned.
The toggle problem was with ibus-mozc, IIRC. The segfault happened with other methods, too.
Can you tell me steps you how to reappear these problems which you mentioned ? I think you should test at other system , at least 12.3.
Yes, my system is (was) FACTORY.
To Huang Peng , Takao Fujiwara and Ma Xiaojun: Can you give us some help ?
Maybe we should test the upgrade paths, at least 12.3, before actually upgrading the stuff in M17N project: install 12.3-beta1 or latest one on a VM (GNOME, KDE, other DE), upgrade to M17N:Devel, and see whether any regression happens.
At the more that half a year, I have tested the upgrade paths (oss to M17N:Devel and M17N to M17N:Devel) at 12.2&12.3(M1,M2 and Beta) On GNOME, KDE and Mate, I didn't find any serious problem, only some minor bugs. Some of them have been fixed. If you really think there are some serious problems, can you please report them to upstream: Huang Peng , Takao Fujiwara and Ma Xiaojun ?
I'll test M17N:Devel again on my system (which is running on the latest FACTORY). Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Wed, Jan 30, 2013 at 2:37 PM, Hillwood Yang <hillwoodroc@gmail.com> wrote:
在 2013-01-29二的 08:30 +0100，Takashi Iwai写道：
At Tue, 29 Jan 2013 14:54:20 +0800, Hillwood Yang wrote:
hello everyone:
1.5.x stable version of ibus , ibus-pinyin , ibus-anthy and ibus-table have been released for a long time, and other ibus input engine also can work with ibus 1.5.1 ，I think we could update them in factory.
Well, now is a bad timing just before 12.3 release. We shouldn't change the devel project too much until 12.3 is released and FACTORY is opened again.
Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block ibus's tray icon , we can't view which engine we use current from tray icon in ibus 1.4.2 . But in ibus 1.5.x , we can view it form the fly box while switching engine if disable ibus build for gnome-settings-daemon , or view it form gnome's language tray icon if enable ibus build for gnome-settings-daemon.
What do you think?
Request#150248: https://build.opensuse.org/request/show/150248
The biggest problems would be the migration and the stability. When I tested ibus 1.5 shortly ago, both failed too badly. Upgrading to M17N:Devel from a system running with ibus-1.4.x (mozc, anthy and m17n) triggered frequent segfaults, even blocked the toggle of IM (likely due to key assignment / policy changes) -- in short, it was just useless on that system.
I found the problem about blocked the toggle of IM only in openSUSE 12.3 (M2 and beta) after force enabled ibus-gjs 3.4.1. I don't know whether you enabled ibus-gjs too. If This is the reason about this problem , we can ignore it, end users should not install ibus-gjs 3.4.1 from M17N:Devel, and it seems that openSUSE don't supply technical support for third party repertories , especially test repertories. ibus-gjs also will not included in openSUSE 12.3 ， it only word in GNOME 3.4.x.
I'm not sure what is the toggle problem. ibus-gjs works with gnome-shell 3.4 and ibus-gjs is no longer needed in gnome-shell 3.6 since ibus was integrated. And right, we have changed the behavior of trigger keys in ibus 1.5.
Ibus-anthy and ibus-m17n always work fine with ibus 1.5 in my three PCs (openSUSE 12.2) and a VirtualBox system (opensuse 12.3). I can't reappear the problem about ibus-anthy and ibus-m17n which you mentioned.
Can you tell me steps you how to reappear these problems which you mentioned ? I think you should test at other system , at least 12.3.
To Huang Peng , Takao Fujiwara and Ma Xiaojun: Can you give us some help ?
Maybe we should test the upgrade paths, at least 12.3, before actually upgrading the stuff in M17N project: install 12.3-beta1 or latest one on a VM (GNOME, KDE, other DE), upgrade to M17N:Devel, and see whether any regression happens.
At the more that half a year, I have tested the upgrade paths (oss to M17N:Devel and M17N to M17N:Devel) at 12.2&12.3(M1,M2 and Beta) On GNOME, KDE and Mate, I didn't find any serious problem, only some minor bugs. Some of them have been fixed. If you really think there are some serious problems, can you please report them to upstream: Huang Peng , Takao Fujiwara and Ma Xiaojun ?
thanks,
Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Wed, 30 Jan 2013 17:15:27 +0900, Takao Fujiwara wrote:
On Wed, Jan 30, 2013 at 2:37 PM, Hillwood Yang <hillwoodroc@gmail.com> wrote:
在 2013-01-29二的 08:30 +0100，Takashi Iwai写道：
At Tue, 29 Jan 2013 14:54:20 +0800, Hillwood Yang wrote:
hello everyone:
1.5.x stable version of ibus , ibus-pinyin , ibus-anthy and ibus-table have been released for a long time, and other ibus input engine also can work with ibus 1.5.1 ，I think we could update them in factory.
Well, now is a bad timing just before 12.3 release. We shouldn't change the devel project too much until 12.3 is released and FACTORY is opened again.
Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block ibus's tray icon , we can't view which engine we use current from tray icon in ibus 1.4.2 . But in ibus 1.5.x , we can view it form the fly box while switching engine if disable ibus build for gnome-settings-daemon , or view it form gnome's language tray icon if enable ibus build for gnome-settings-daemon.
What do you think?
Request#150248: https://build.opensuse.org/request/show/150248
The biggest problems would be the migration and the stability. When I tested ibus 1.5 shortly ago, both failed too badly. Upgrading to M17N:Devel from a system running with ibus-1.4.x (mozc, anthy and m17n) triggered frequent segfaults, even blocked the toggle of IM (likely due to key assignment / policy changes) -- in short, it was just useless on that system.
I found the problem about blocked the toggle of IM only in openSUSE 12.3 (M2 and beta) after force enabled ibus-gjs 3.4.1. I don't know whether you enabled ibus-gjs too. If This is the reason about this problem , we can ignore it, end users should not install ibus-gjs 3.4.1 from M17N:Devel, and it seems that openSUSE don't supply technical support for third party repertories , especially test repertories. ibus-gjs also will not included in openSUSE 12.3 ， it only word in GNOME 3.4.x.
I'm not sure what is the toggle problem. ibus-gjs works with gnome-shell 3.4 and ibus-gjs is no longer needed in gnome-shell 3.6 since ibus was integrated.
And right, we have changed the behavior of trigger keys in ibus 1.5.
I tested right now with the latest 12.3 (FACTORY) and M17N:Devel. My desktop is XFCE. The biggest problem is that now ibus itself manages the keyboard layout. This really sucks, especially when you have own modified keyboard layout. Since now IM activation/deactivation is handled like the change of different IMs (e.g. "English US keyboard" and "Mozc"), if you haven't registered the proper IMs beforehand, you'll be lost. This incompatibility is confusing and it took long time to figure out for me. I know that you can activate/deactivate IM even in each method (e.g. via Henkan key), too. But, for example, Mozc doesn't define such key bindings for non-Japanese keyboards properly. Thus if you have only US keyboard, you can't manage it at all. Maybe because of that reason (policy change about keyboard layout management), the IM activation state isn't shown in the tray icon. So if you activate/deactivate IM in Mozc, you can't see whether it's in preedit mode or not. Also maybe because of the same reason, the IM is always activated at the login time. When I choose Mozc as default, it starts in the preedit mode for typing Japanese after login. I have to switch back to English USA layout or turn off IM manually. There is a global "go to next IM" key binding, yes. But if you have more than two IMs, switching Latin and Japanese doesn't work like before. Again, the keyboard layout override is confusing when you already have a modified layout. This can be a big reason I'll stop using the new ibus from now on. The keyboard layout isn't a job of IM. One good news is that I haven't see segfaults I had hit ago :) So... my impression is that it's still in rough edge. And the new keyboard handling is really confusing for the old user like me. Maybe it'd be good for people who only use two IMs (one Latin and one native IM). thanks, Takashi
Ibus-anthy and ibus-m17n always work fine with ibus 1.5 in my three PCs (openSUSE 12.2) and a VirtualBox system (opensuse 12.3). I can't reappear the problem about ibus-anthy and ibus-m17n which you mentioned.
Can you tell me steps you how to reappear these problems which you mentioned ? I think you should test at other system , at least 12.3.
To Huang Peng , Takao Fujiwara and Ma Xiaojun: Can you give us some help ?
Maybe we should test the upgrade paths, at least 12.3, before actually upgrading the stuff in M17N project: install 12.3-beta1 or latest one on a VM (GNOME, KDE, other DE), upgrade to M17N:Devel, and see whether any regression happens.
At the more that half a year, I have tested the upgrade paths (oss to M17N:Devel and M17N to M17N:Devel) at 12.2&12.3(M1,M2 and Beta) On GNOME, KDE and Mate, I didn't find any serious problem, only some minor bugs. Some of them have been fixed. If you really think there are some serious problems, can you please report them to upstream: Huang Peng , Takao Fujiwara and Ma Xiaojun ?
thanks,
Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Thu, Jan 31, 2013 at 2:51 AM, Takashi Iwai <tiwai@suse.de> wrote:
At Wed, 30 Jan 2013 17:15:27 +0900, Takao Fujiwara wrote:
On Wed, Jan 30, 2013 at 2:37 PM, Hillwood Yang <hillwoodroc@gmail.com> wrote:
在 2013-01-29二的 08:30 +0100，Takashi Iwai写道：
At Tue, 29 Jan 2013 14:54:20 +0800, Hillwood Yang wrote:
hello everyone:
1.5.x stable version of ibus , ibus-pinyin , ibus-anthy and ibus-table have been released for a long time, and other ibus input engine also can work with ibus 1.5.1 ，I think we could update them in factory.
Well, now is a bad timing just before 12.3 release. We shouldn't change the devel project too much until 12.3 is released and FACTORY is opened again.
Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block ibus's tray icon , we can't view which engine we use current from tray icon in ibus 1.4.2 . But in ibus 1.5.x , we can view it form the fly box while switching engine if disable ibus build for gnome-settings-daemon , or view it form gnome's language tray icon if enable ibus build for gnome-settings-daemon.
What do you think?
Request#150248: https://build.opensuse.org/request/show/150248
The biggest problems would be the migration and the stability. When I tested ibus 1.5 shortly ago, both failed too badly. Upgrading to M17N:Devel from a system running with ibus-1.4.x (mozc, anthy and m17n) triggered frequent segfaults, even blocked the toggle of IM (likely due to key assignment / policy changes) -- in short, it was just useless on that system.
I found the problem about blocked the toggle of IM only in openSUSE 12.3 (M2 and beta) after force enabled ibus-gjs 3.4.1. I don't know whether you enabled ibus-gjs too. If This is the reason about this problem , we can ignore it, end users should not install ibus-gjs 3.4.1 from M17N:Devel, and it seems that openSUSE don't supply technical support for third party repertories , especially test repertories. ibus-gjs also will not included in openSUSE 12.3 ， it only word in GNOME 3.4.x.
I'm not sure what is the toggle problem. ibus-gjs works with gnome-shell 3.4 and ibus-gjs is no longer needed in gnome-shell 3.6 since ibus was integrated.
And right, we have changed the behavior of trigger keys in ibus 1.5.
I tested right now with the latest 12.3 (FACTORY) and M17N:Devel. My desktop is XFCE.
The biggest problem is that now ibus itself manages the keyboard layout. This really sucks, especially when you have own modified keyboard layout.
Since now IM activation/deactivation is handled like the change of different IMs (e.g. "English US keyboard" and "Mozc"), if you haven't registered the proper IMs beforehand, you'll be lost. This incompatibility is confusing and it took long time to figure out for me.
I know that you can activate/deactivate IM even in each method (e.g. via Henkan key), too. But, for example, Mozc doesn't define such key bindings for non-Japanese keyboards properly. Thus if you have only US keyboard, you can't manage it at all.
I suppose JP keyboard and Japanese IMEs (configured as JP keyboard) instead of US keyboard in case you use Henkan key. ibus-setup 1.5 can configure the trigger keys but it's not for each IME but the global setting and I think it would be almost same with 1.4.
Maybe because of that reason (policy change about keyboard layout management), the IM activation state isn't shown in the tray icon. So if you activate/deactivate IM in Mozc, you can't see whether it's in preedit mode or not.
Probably I don't understand the problem. ibus panel icon shows the current engine.
Also maybe because of the same reason, the IM is always activated at the login time. When I choose Mozc as default, it starts in the preedit mode for typing Japanese after login. I have to switch back to English USA layout or turn off IM manually.
Yes, it's good the default is an ibus keymap engine but not input method engine.
There is a global "go to next IM" key binding, yes. But if you have more than two IMs, switching Latin and Japanese doesn't work like before.
Again, the keyboard layout override is confusing when you already have a modified layout. This can be a big reason I'll stop using the new ibus from now on. The keyboard layout isn't a job of IM.
Currently ibus suppose the XKB layout and variant per engine and the global XKB options. Now ibus-anthy provides the customization of the keymap too.
One good news is that I haven't see segfaults I had hit ago :)
So... my impression is that it's still in rough edge. And the new keyboard handling is really confusing for the old user like me. Maybe it'd be good for people who only use two IMs (one Latin and one native IM).
thanks,
Takashi
Ibus-anthy and ibus-m17n always work fine with ibus 1.5 in my three PCs (openSUSE 12.2) and a VirtualBox system (opensuse 12.3). I can't reappear the problem about ibus-anthy and ibus-m17n which you mentioned.
Can you tell me steps you how to reappear these problems which you mentioned ? I think you should test at other system , at least 12.3.
To Huang Peng , Takao Fujiwara and Ma Xiaojun: Can you give us some help ?
Maybe we should test the upgrade paths, at least 12.3, before actually upgrading the stuff in M17N project: install 12.3-beta1 or latest one on a VM (GNOME, KDE, other DE), upgrade to M17N:Devel, and see whether any regression happens.
At the more that half a year, I have tested the upgrade paths (oss to M17N:Devel and M17N to M17N:Devel) at 12.2&12.3(M1,M2 and Beta) On GNOME, KDE and Mate, I didn't find any serious problem, only some minor bugs. Some of them have been fixed. If you really think there are some serious problems, can you please report them to upstream: Huang Peng , Takao Fujiwara and Ma Xiaojun ?
thanks,
Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
At Thu, 31 Jan 2013 09:51:05 +0900, Takao Fujiwara wrote:
On Thu, Jan 31, 2013 at 2:51 AM, Takashi Iwai <tiwai@suse.de> wrote:
At Wed, 30 Jan 2013 17:15:27 +0900, Takao Fujiwara wrote:
On Wed, Jan 30, 2013 at 2:37 PM, Hillwood Yang <hillwoodroc@gmail.com> wrote:
在 2013-01-29二的 08:30 +0100，Takashi Iwai写道：
At Tue, 29 Jan 2013 14:54:20 +0800, Hillwood Yang wrote:
hello everyone:
1.5.x stable version of ibus , ibus-pinyin , ibus-anthy and ibus-table have been released for a long time, and other ibus input engine also can work with ibus 1.5.1 ，I think we could update them in factory.
Well, now is a bad timing just before 12.3 release. We shouldn't change the devel project too much until 12.3 is released and FACTORY is opened again.
Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block ibus's tray icon , we can't view which engine we use current from tray icon in ibus 1.4.2 . But in ibus 1.5.x , we can view it form the fly box while switching engine if disable ibus build for gnome-settings-daemon , or view it form gnome's language tray icon if enable ibus build for gnome-settings-daemon.
What do you think?
Request#150248: https://build.opensuse.org/request/show/150248
The biggest problems would be the migration and the stability. When I tested ibus 1.5 shortly ago, both failed too badly. Upgrading to M17N:Devel from a system running with ibus-1.4.x (mozc, anthy and m17n) triggered frequent segfaults, even blocked the toggle of IM (likely due to key assignment / policy changes) -- in short, it was just useless on that system.
I found the problem about blocked the toggle of IM only in openSUSE 12.3 (M2 and beta) after force enabled ibus-gjs 3.4.1. I don't know whether you enabled ibus-gjs too. If This is the reason about this problem , we can ignore it, end users should not install ibus-gjs 3.4.1 from M17N:Devel, and it seems that openSUSE don't supply technical support for third party repertories , especially test repertories. ibus-gjs also will not included in openSUSE 12.3 ， it only word in GNOME 3.4.x.
I'm not sure what is the toggle problem. ibus-gjs works with gnome-shell 3.4 and ibus-gjs is no longer needed in gnome-shell 3.6 since ibus was integrated.
And right, we have changed the behavior of trigger keys in ibus 1.5.
I tested right now with the latest 12.3 (FACTORY) and M17N:Devel. My desktop is XFCE.
The biggest problem is that now ibus itself manages the keyboard layout. This really sucks, especially when you have own modified keyboard layout.
Since now IM activation/deactivation is handled like the change of different IMs (e.g. "English US keyboard" and "Mozc"), if you haven't registered the proper IMs beforehand, you'll be lost. This incompatibility is confusing and it took long time to figure out for me.
I know that you can activate/deactivate IM even in each method (e.g. via Henkan key), too. But, for example, Mozc doesn't define such key bindings for non-Japanese keyboards properly. Thus if you have only US keyboard, you can't manage it at all.
I suppose JP keyboard and Japanese IMEs (configured as JP keyboard) instead of US keyboard in case you use Henkan key.
No, I do _not_ use Henkan key. As default, Mozc provides the key bindings only for Japanese key layouts. The activation/deactivation is also included in Mozc's key action, but only Henkan & co are assigned, nothing that you can input from non-Japanese key layout.
ibus-setup 1.5 can configure the trigger keys but it's not for each IME but the global setting and I think it would be almost same with 1.4.
Maybe that's the problem. The global trigger key is gone completely. On 1.4, you could choose "Turn off input method" when you left-click the tray icon while IME is running. And in the global preference dialog, you had "Enable" or "disable" key binding. On 1.5, you can't choose "turn off input method" in tray menu, and there is no "enable" or "disable" key setup in the global preference dialog. Only "Next input method" as before. In my case, I used Ctrl+Space for toggling the IM. This was assigned to "next input method" as default on 1.5. So... is really the deactivation of IBUS itself still supported on 1.5? Or you have to switch XKB (or a key layout) IME and Mozc/Anthy whatever, for changing the Latin and the CJK inputs?
Maybe because of that reason (policy change about keyboard layout management), the IM activation state isn't shown in the tray icon. So if you activate/deactivate IM in Mozc, you can't see whether it's in preedit mode or not.
Probably I don't understand the problem. ibus panel icon shows the current engine.
Yes. But you can't turn off IM. In the past, when you "deactivated" IM, the try icon changed to a gray keyboard icon. Now Mozc has a "deactivated" state (maybe locally in IME), but it doesn't change the icon state.
Also maybe because of the same reason, the IM is always activated at the login time. When I choose Mozc as default, it starts in the preedit mode for typing Japanese after login. I have to switch back to English USA layout or turn off IM manually.
Yes, it's good the default is an ibus keymap engine but not input method engine.
There is a global "go to next IM" key binding, yes. But if you have more than two IMs, switching Latin and Japanese doesn't work like before.
Again, the keyboard layout override is confusing when you already have a modified layout. This can be a big reason I'll stop using the new ibus from now on. The keyboard layout isn't a job of IM.
Currently ibus suppose the XKB layout and variant per engine and the global XKB options. Now ibus-anthy provides the customization of the keymap too.
This brings lots of confusion... The key layout is changed out of sudden when you use a different IME. Then, if you want to achieve the same layout, you have to customize the layout of each IME. (Some IME did it in the past, too, but not that chaos all the time. At least you could turn off IM, and you got the normal layout.) thanks, Takashi
One good news is that I haven't see segfaults I had hit ago :)
So... my impression is that it's still in rough edge. And the new keyboard handling is really confusing for the old user like me. Maybe it'd be good for people who only use two IMs (one Latin and one native IM).
thanks,
Takashi
Ibus-anthy and ibus-m17n always work fine with ibus 1.5 in my three PCs (openSUSE 12.2) and a VirtualBox system (opensuse 12.3). I can't reappear the problem about ibus-anthy and ibus-m17n which you mentioned.
Can you tell me steps you how to reappear these problems which you mentioned ? I think you should test at other system , at least 12.3.
To Huang Peng , Takao Fujiwara and Ma Xiaojun: Can you give us some help ?
Maybe we should test the upgrade paths, at least 12.3, before actually upgrading the stuff in M17N project: install 12.3-beta1 or latest one on a VM (GNOME, KDE, other DE), upgrade to M17N:Devel, and see whether any regression happens.
At the more that half a year, I have tested the upgrade paths (oss to M17N:Devel and M17N to M17N:Devel) at 12.2&12.3(M1,M2 and Beta) On GNOME, KDE and Mate, I didn't find any serious problem, only some minor bugs. Some of them have been fixed. If you really think there are some serious problems, can you please report them to upstream: Huang Peng , Takao Fujiwara and Ma Xiaojun ?
thanks,
Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Thu, Jan 31, 2013 at 3:48 PM, Takashi Iwai <tiwai@suse.de> wrote:
At Thu, 31 Jan 2013 09:51:05 +0900, Takao Fujiwara wrote:
On Thu, Jan 31, 2013 at 2:51 AM, Takashi Iwai <tiwai@suse.de> wrote:
At Wed, 30 Jan 2013 17:15:27 +0900, Takao Fujiwara wrote:
On Wed, Jan 30, 2013 at 2:37 PM, Hillwood Yang <hillwoodroc@gmail.com> wrote:
在 2013-01-29二的 08:30 +0100，Takashi Iwai写道：
At Tue, 29 Jan 2013 14:54:20 +0800, Hillwood Yang wrote: > > hello everyone: > > 1.5.x stable version of ibus , ibus-pinyin , ibus-anthy and ibus-table > have been released for a long time, and other ibus input engine also can > work with ibus 1.5.1 ，I think we could update them in factory.
Well, now is a bad timing just before 12.3 release. We shouldn't change the devel project too much until 12.3 is released and FACTORY is opened again.
> Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block > ibus's tray icon , we can't view which engine we use current from tray > icon in ibus 1.4.2 . But in ibus 1.5.x , we can view it form the fly box > while switching engine if disable ibus build for gnome-settings-daemon , > or view it form gnome's language tray icon if enable ibus build for > gnome-settings-daemon. > > What do you think? > > Request#150248: > https://build.opensuse.org/request/show/150248
The biggest problems would be the migration and the stability. When I tested ibus 1.5 shortly ago, both failed too badly. Upgrading to M17N:Devel from a system running with ibus-1.4.x (mozc, anthy and m17n) triggered frequent segfaults, even blocked the toggle of IM (likely due to key assignment / policy changes) -- in short, it was just useless on that system.
I found the problem about blocked the toggle of IM only in openSUSE 12.3 (M2 and beta) after force enabled ibus-gjs 3.4.1. I don't know whether you enabled ibus-gjs too. If This is the reason about this problem , we can ignore it, end users should not install ibus-gjs 3.4.1 from M17N:Devel, and it seems that openSUSE don't supply technical support for third party repertories , especially test repertories. ibus-gjs also will not included in openSUSE 12.3 ， it only word in GNOME 3.4.x.
I'm not sure what is the toggle problem. ibus-gjs works with gnome-shell 3.4 and ibus-gjs is no longer needed in gnome-shell 3.6 since ibus was integrated.
And right, we have changed the behavior of trigger keys in ibus 1.5.
I tested right now with the latest 12.3 (FACTORY) and M17N:Devel. My desktop is XFCE.
The biggest problem is that now ibus itself manages the keyboard layout. This really sucks, especially when you have own modified keyboard layout.
Since now IM activation/deactivation is handled like the change of different IMs (e.g. "English US keyboard" and "Mozc"), if you haven't registered the proper IMs beforehand, you'll be lost. This incompatibility is confusing and it took long time to figure out for me.
I know that you can activate/deactivate IM even in each method (e.g. via Henkan key), too. But, for example, Mozc doesn't define such key bindings for non-Japanese keyboards properly. Thus if you have only US keyboard, you can't manage it at all.
I suppose JP keyboard and Japanese IMEs (configured as JP keyboard) instead of US keyboard in case you use Henkan key.
No, I do _not_ use Henkan key. As default, Mozc provides the key bindings only for Japanese key layouts. The activation/deactivation is also included in Mozc's key action, but only Henkan & co are assigned, nothing that you can input from non-Japanese key layout.
ibus-setup 1.5 can configure the trigger keys but it's not for each IME but the global setting and I think it would be almost same with 1.4.
Maybe that's the problem. The global trigger key is gone completely.
On 1.4, you could choose "Turn off input method" when you left-click the tray icon while IME is running. And in the global preference dialog, you had "Enable" or "disable" key binding.
On 1.5, you can't choose "turn off input method" in tray menu, and there is no "enable" or "disable" key setup in the global preference dialog. Only "Next input method" as before.
In my case, I used Ctrl+Space for toggling the IM. This was assigned to "next input method" as default on 1.5.
So... is really the deactivation of IBUS itself still supported on 1.5? Or you have to switch XKB (or a key layout) IME and Mozc/Anthy whatever, for changing the Latin and the CJK inputs?
Thanks for the explanation. Right, ibus 1.5 does not support activation/deactivation since ibus switches input method and keymap engines so that users manage those under the same UI: https://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/InputLangua... I'm thinking your issue might be resolved by engine specific trigger keys besides the global trigger keys but we don't implement it yet. Probably I think the feature is requested in case more than three ibus engines are configured. If one keymap engine and one input method engine are configured, Control+space could switches each other.
Maybe because of that reason (policy change about keyboard layout management), the IM activation state isn't shown in the tray icon. So if you activate/deactivate IM in Mozc, you can't see whether it's in preedit mode or not.
Probably I don't understand the problem. ibus panel icon shows the current engine.
Yes. But you can't turn off IM. In the past, when you "deactivated" IM, the try icon changed to a gray keyboard icon. Now Mozc has a "deactivated" state (maybe locally in IME), but it doesn't change the icon state.
Also maybe because of the same reason, the IM is always activated at the login time. When I choose Mozc as default, it starts in the preedit mode for typing Japanese after login. I have to switch back to English USA layout or turn off IM manually.
Yes, it's good the default is an ibus keymap engine but not input method engine.
There is a global "go to next IM" key binding, yes. But if you have more than two IMs, switching Latin and Japanese doesn't work like before.
Again, the keyboard layout override is confusing when you already have a modified layout. This can be a big reason I'll stop using the new ibus from now on. The keyboard layout isn't a job of IM.
Currently ibus suppose the XKB layout and variant per engine and the global XKB options. Now ibus-anthy provides the customization of the keymap too.
This brings lots of confusion... The key layout is changed out of sudden when you use a different IME. Then, if you want to achieve the same layout, you have to customize the layout of each IME.
I also think to support the use-system-keyboard in ibus 1.4 but I think it will be implemented after GSettingsList is implemented in GNOME 3.8. So currently each IME needs to be customized until ibus support it.
(Some IME did it in the past, too, but not that chaos all the time. At least you could turn off IM, and you got the normal layout.)
thanks,
Takashi
One good news is that I haven't see segfaults I had hit ago :)
So... my impression is that it's still in rough edge. And the new keyboard handling is really confusing for the old user like me. Maybe it'd be good for people who only use two IMs (one Latin and one native IM).
thanks,
Takashi
Ibus-anthy and ibus-m17n always work fine with ibus 1.5 in my three PCs (openSUSE 12.2) and a VirtualBox system (opensuse 12.3). I can't reappear the problem about ibus-anthy and ibus-m17n which you mentioned.
Can you tell me steps you how to reappear these problems which you mentioned ? I think you should test at other system , at least 12.3.
To Huang Peng , Takao Fujiwara and Ma Xiaojun: Can you give us some help ?
Maybe we should test the upgrade paths, at least 12.3, before actually upgrading the stuff in M17N project: install 12.3-beta1 or latest one on a VM (GNOME, KDE, other DE), upgrade to M17N:Devel, and see whether any regression happens.
At the more that half a year, I have tested the upgrade paths (oss to M17N:Devel and M17N to M17N:Devel) at 12.2&12.3(M1,M2 and Beta) On GNOME, KDE and Mate, I didn't find any serious problem, only some minor bugs. Some of them have been fixed. If you really think there are some serious problems, can you please report them to upstream: Huang Peng , Takao Fujiwara and Ma Xiaojun ?
thanks,
Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Hi Takashi, Vincent, Takao and all I reappeared the problem about blocked the toggle of IM yesterday, after I installed typelib-1_0-IBus-1_0. I think the problem is like this: Gnome-shell through IBus-1.0.typelib 1.5.x to judge whether ibus 1.5.x was installed. If IBus-1.0.typelib 1.5.x was installed, Gnome-shell would force enable gjs ui to instead ibus's native gtk3 panel ui, and prevented ibus responded shortcut keys, so that we can't use Ctrl+Space to switch input engine. This problem must cause by the Gnome 3.6. Can you fix it, Vincent? Maybe we should report this bug to Gnome's bugzilla? But it will be too late to wait it is fixed by upstream. Of course, If we enable ibus option to build gnome-settings-daemon, this problem will disappear. Takashi Iwai写道:
The biggest problems would be the migration and the stability. When I tested ibus 1.5 shortly ago, both failed too badly. Upgrading to M17N:Devel from a system running with ibus-1.4.x (mozc, anthy and m17n) triggered frequent segfaults, even blocked the toggle of IM (likely due to key assignment / policy changes) -- in short, it was just useless on that system.
Maybe we should test the upgrade paths, at least 12.3, before actually upgrading the stuff in M17N project: install 12.3-beta1 or latest one on a VM (GNOME, KDE, other DE), upgrade to M17N:Devel, and see whether any regression happens.
thanks,
Takashi
The problem about tray icon is also too serious! And the tray icon is not a gnome-shell extension, it is a ibus's native tray icon. thanks, Hillwood 在 2013-01-30三的 07:48 +0100，Vincent Untz写道： Le mercredi 30 janvier 2013, à 14:24 +0900, Fuminobu TAKEYAMA a écrit :
Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block ibus's tray icon , we can't view which engine we use current from tray icon in ibus 1.4.2 .
Oh.. ibus's gnome tray icon has gone away. Shall we fix it for 12.3? It is better solution for 12.3.
Vincent, do you know any changes in GNOME 3.6 that may prevent tray icon? The icon is placed at the top of screen in 12.2.
If it was added at the top of the screen in 12.2, then I guess it was a gnome-shell extension. The tray icon should still be there in the bottom right corner, though (assuming it's a standard tray icon).
Otherwise, I can't think of anything else right now.
Vincent
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Thu, Jan 31, 2013 at 4:25 PM, Hillwood Yang <hillwoodroc@gmail.com> wrote:
was installed. If IBus-1.0.typelib 1.5.x was installed, Gnome-shell would force enable gjs ui to instead ibus's native gtk3 panel ui, and prevented ibus responded shortcut keys, so that we can't use Ctrl+Space to switch input engine. This problem must cause by the Gnome 3.6. Can
Use gnome-control-center to set the trigger keys. ibus is now integrated in gnome. fujiwara -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Hi Hillwood, Vincent, Iwai-san and all, I also think it is still early to put our ibus-1.5.1 into M17N and Factory. The problem of layout-specific key binding is not resolved completely yet. I don't know why but this problem is suddenly resolved on one of my machine. However it still exists on another machine. On KDE, there is something wrong with ibus's pop-up menu. When I click ibus's tray icon, it appears but disappears immediately. This problem is also happens on the latter machine. I need more time to make sure what is happening on the latter machine.
Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block ibus's tray icon , we can't view which engine we use current from tray icon in ibus 1.4.2 .
Oh.. ibus's gnome tray icon has gone away. Shall we fix it for 12.3? It is better solution for 12.3. Vincent, do you know any changes in GNOME 3.6 that may prevent tray icon? The icon is placed at the top of screen in 12.2. Best regards, Fuminobu TAKEYAMA (2013/01/29 15:54), Hillwood Yang wrote:
hello everyone:
1.5.x stable version of ibus , ibus-pinyin , ibus-anthy and ibus-table have been released for a long time, and other ibus input engine also can work with ibus 1.5.1 ，I think we could update them in factory. Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block ibus's tray icon , we can't view which engine we use current from tray icon in ibus 1.4.2 . But in ibus 1.5.x , we can view it form the fly box while switching engine if disable ibus build for gnome-settings-daemon , or view it form gnome's language tray icon if enable ibus build for gnome-settings-daemon.
What do you think?
Request#150248: https://build.opensuse.org/request/show/150248
-- Fuminobu TAKEYAMA -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Le mercredi 30 janvier 2013, à 14:24 +0900, Fuminobu TAKEYAMA a écrit :
Ibus 1.4.2 has been unfit to work in gnome 3.6. Gnome 3.6 can block ibus's tray icon , we can't view which engine we use current from tray icon in ibus 1.4.2 .
Oh.. ibus's gnome tray icon has gone away. Shall we fix it for 12.3? It is better solution for 12.3.
Vincent, do you know any changes in GNOME 3.6 that may prevent tray icon? The icon is placed at the top of screen in 12.2.
If it was added at the top of the screen in 12.2, then I guess it was a gnome-shell extension. The tray icon should still be there in the bottom right corner, though (assuming it's a standard tray icon). Otherwise, I can't think of anything else right now. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
participants (5)
-
Fuminobu TAKEYAMA -
Hillwood Yang -
Takao Fujiwara -
Takashi Iwai -
Vincent Untz