forked from phuang/ibus
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[pull] master from phuang:master #1
Open
pull
wants to merge
410
commits into
definite:master
Choose a base branch
from
phuang:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Please note that gcc's warn_unused_result check is enforced on the build environment. Anyway, I believe it's good to check the return value in this case. BUG=none TEST=ran emerge-x86-generic ibus. Review URL: http://codereview.appspot.com/3904044
This change is similar to ibus@19247aa. The flag can prevent unnecessary communications between ibus-daemon and e.g. engines like this: $ . ~/.config/ibus/bus/*-unix-0 ; dbus-monitor --address $IBUS_ADDRESS 2>&1 | tee /tmp/ibus.log ... method call sender=org.freedesktop.DBus -> dest=(null destination) serial=3 path=/org/freedesktop/IBus/Factory; interface=org.freedesktop.IBus.Factory; member=CreateEngine string "mozc-jp" method return sender=:1.15 -> dest=org.freedesktop.DBus reply_serial=3 object path "/org/freedesktop/IBus/Engine/1" method call sender=org.freedesktop.DBus -> dest=(null destination) serial=4 path=/org/freedesktop/IBus/Engine/1; interface=org.freedesktop.DBus.Properties; member=GetAll string "org.freedesktop.IBus.Engine" method return sender=:1.15 -> dest=org.freedesktop.DBus reply_serial=4 array [ ] Calling an engine's org.freedesktop.DBus.Properties.GetAll method when the engine is created is unnecessary for ibus-daemon, while it's not harmful though. BUG=none TEST=verified using dbus-monitor that ibus-daemon does not call GetAll anymore. Review URL: http://codereview.appspot.com/4036041
According to setup/keyboardshortcut.py, "Control" seems to be correct. BUG=none TEST=compile ibus with --enable-memconf, start ibus-daemon, start ibus-setup, click "..." button for the "Enable or disable" hotkey, then verify that the "Control" checkbox in the pop-up dialog is checked from the beginning. Review URL: http://codereview.appspot.com/4017042
libdbus expects each message serial is greater than 0. https://code.google.com/p/ibus/issues/detail?id=1186 BUG=none TEST=manual test described in the issue#1186 Review URL: http://codereview.appspot.com/4050041
… engines. BUG=none TEST=manually Review URL: http://codereview.appspot.com/4054041
BUG=http://crosbug.com/11011 TEST=manually Review URL: http://codereview.appspot.com/4037042
The g_variant_get returns NULL when the IPC call times out. BUG=none TEST=none Review URL: http://codereview.appspot.com/3974043
…fety. 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
…get_global_engine(). 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
Otherwise, we might miss the first a few DBus and IBus signals. BUG=http://crosbug.com/11144 TEST=see the bug. Review URL: http://codereview.appspot.com/4029043
…ror. BUG=chromium-os:10750 TEST=on Linux desktop Review URL: http://codereview.appspot.com/3970044
…igservice.c. 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
BUG=http://code.google.com/p/ibus/issues/detail?id=1194 TEST=Tested in Ubuntu 10.10 Review URL: http://codereview.appspot.com/4084046
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
BUG= TEST=make dpkg Review URL: http://codereview.appspot.com/4013046
BUG=chromium-os:11421 TEST=manually done on Chrome OS. Review URL: http://codereview.appspot.com/3989060
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 <[email protected]>.
…nally (i.e. not toggle.) I'll update ibus/po/*po files if the change looks good to you. BUG=http://code.google.com/p/ibus/issues/detail?id=1173 TEST=manually Review URL: http://codereview.appspot.com/3807047
BUG=crosbug.com/11479 Review URL: http://codereview.appspot.com/4186041
BUG=1173 Review URL: http://codereview.appspot.com/4181044
BUG=1201 Review URL: http://codereview.appspot.com/4171046 Patch from Ahmad Sharif <[email protected]>.
…ess_key_event_done in order to handle IPC errors correctly. Review URL: http://codereview.appspot.com/4171049
…he keyval from X as-is. 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
TEST=Linux desktop Review URL: https://codereview.appspot.com/5690064
TEST=Linux Desktop Review URL: https://codereview.appspot.com/5517048
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )