./autogen.sh
./configure --enable-gtk-doc
make dpkg
cp ppa/ibus-1.3.99.20110309/debian/libibus-1.0-0/DEBIAN/symbols debian/libibus-1.0-0.symbols
vi debian/libibus-1.0-0.symbols # remove "-1phuang1~maverick1"
make dpkg # confirm that lintian does not report an error.
Review URL: http://codereview.appspot.com/4253068
Check global_previous_engine_name when the previous engine is requested and rewrite it if necessary.
This change ensures that the "previous_engine" hotkey (Ctrl+space on Chrome OS) always works
whenever two or more engines are preloaded.
Currently, Ctrl+space could become NOP by the following scenarios (http://crosbug.com/6609):
(1)
1. preload engines A, B, C.
2. switch to A.
3. switch to B.
4. at this point, ctrl+space works fine. It selectes A and B alternately.
5. switch to A.
6. remove B from the preloaded engline list.
7. at this point, ctrl+space suddenly becomes NOP although C is still preloaded.
This is because the callback function of ctrl+space detects
global_previous_engine_name (i.e. B) is removed and automatically selects A (not
C) as a global_previous_engine_name.
(2)
1. preload engines A, B.
2. switch to A.
3. switch to B.
4. at this point, ctrl+space works fine. It selectes A and B alternately.
5. switch to A.
6. remove B from the preloaded engline list.
7. press ctrl+space several times, confirm that nothing happens (this is
expected since only one engine, A, is preloaded).
8. preload additional engine, C.
9. at this point, ctrl+space is still NOP although two engines, A and C, are
preloaded.
Modified src/tests/ibus-bus.c so that it could be compiled with ibus-1.3.99 as well.
BUG=chromium-os:12581
TEST=added async api tests to the src/tests/ibus-bus.c and ran it locally.
Review URL: http://codereview.appspot.com/4179061
The race problem:
1. global engine == A
2. call SetGlobalEngine(B) asynchronously
3. call SetGlobalEngine(A) immediately
3.1 Because step 2 is not finished, so the global engine is still A,
and SetGlobalEngine(A) returns sucessfully.
4. SetGlobalEngine(B) is completed and the global engine becomes B
BUG=http://crosbug.com/12414
TEST=Linux desktop
Review URL: http://codereview.appspot.com/4250041
This makes it possible for a client to know the current global engine w/o issuing GetGlobalEngine reqeust.
BUG=chromium-os:11908
Review URL: http://codereview.appspot.com/4177045
This is a fix for https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/716314. Calling setlocale(LC_ALL, NULL); in the function seems not to be a good idea since the function could return a complex string like "LC_CTYPE=ja_JP.UTF-8;LC_NUMERIC=C;LC..." when two or more values are used for LC_xxx variables (e.g. ja_JP.UTF-8 and C.)
BUG=1204
Review URL: http://codereview.appspot.com/4160046
I think this is important for supporting non-US keyboards like a Japanese-106 keyboard correctly.
Currently, when use_sys_layout config is unchecked (the default), ibus-daemon discards a keyval being passed from X, and regenerates a keyval from a keycode assuming the US layout.
However, I believe this behavior is not good for non-US keyboard layout users (e.g. Japanese or Korean keyboard users.) For example, the Japanese 106 keyboard has a key called Zenkaku_Hankaku (全角_半角, whose keycode is 49) on the left hand of the '1' key, and most users want to use the key for toggling IME. But, even if a user set 'Zenkaku_Hankaku' as the toggle hotkey using ibus-setup, the user cannot toggle IME unless the 'Use system keyboard layout' option is explicitly turned on. This is because when use_sys_layout is unchecked, ibus-daemon treats the Zenkaku_Hankaku key press (keycode=49) as tilde (~) key press (remember that the tilde's keycode is also 49 in the US keyboard layout.) This is very inconvenient and confusing.
Please also note that the hotkey configuration tool in ibus-setup always respects a keyval from X, and never checks the use_sys_layout value.
Review URL: http://codereview.appspot.com/4173046
How to reproduce the deadlock on a desktop Linux like Ubuntu Maverick:
1. Add 20 seconds sleep in the beginning of the main() function of an engine (e.g. ibus-engine-mozc). See http://crosbug.com/11379#c16 .
2. Set preload_engines to "mozc" using ibus-setup.
3. Start ibus-daemon.
4. press the trigger hotkey twice within the 20 seconds.
Expected:
The second trigger hotkey press cancels the bus_engine_proxy_new operation started by the first one.
Actual:
ibus-daemon freezes. Stack trace: http://crosbug.com/11379#c20
BUG=http://crosbug.com/11379
TEST=see the steps above.
Review URL: http://codereview.appspot.com/4125053
Patch from phuang <shawn.p.huang@gmail.com>.
Some application may want to integrate with ibus directly, and want to
use async mode for processing key events. So I make
ibus_input_context_process_key_event to be an async function,
and also added ibus_input_context_process_key_event_sync.
Fix problem in introspection of Engine.
BUG=none
TEST=Tested in Ubuntu 10.10
Review URL: http://codereview.appspot.com/4032044
I don't think that GDBus library in glib-2.26.[01] uses the information to filter out undefined signals, but just in case.
BUG=none
TEST=manually
Review URL: http://codereview.appspot.com/4015043
If focus moves between the two API calls, ibus_bus_get_global_engine() might return an unexpected engine name:
1. context A is focused, and the current global engine is "X".
2. ibus_bus_set_global_engine("Y") is called.
3. a user moves the focus from A to B. First, A's engine is set to NULL in bus_ibus_impl_set_focused_context(). Then, in the same function, B's engine is set to "X" (not "Y") since the _ibus_set_global_engine asynchronous call is not finished yet.
4. ibus_bus_set_global_engine("Y") async call successfully finishes. Context A's (not B's) engine is set to "Y", but context B, which has a focus, is not updated.
5. ibus_bus_get_global_engine() is called.
expected:
Y is returned.
actual:
X is returned. Since the context B has a focus, and B's engine is X.
BUG=http://crosbug.com/11031
TEST=see the bug
Review URL: http://codereview.appspot.com/4063041
Unset the own flag of priv->config so that the config proxy object never destroys the config service even if a client wrongly unref()s the priv->config object.
BUG=none
TEST=manually
Review URL: http://codereview.appspot.com/4060041
Peng Huang
Zach Kuznia
fujiwarat
Yusuke Sato
James Su
Ahmad Sharif