Skip to content
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
wants to merge 410 commits into
base: master
Choose a base branch
from
Open

Conversation

pull[bot]
Copy link

@pull pull bot commented Apr 12, 2024

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 : )

yusukes and others added 30 commits January 12, 2011 22:44
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
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
…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
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=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
…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
phuang and others added 28 commits February 21, 2012 11:52
@pull pull bot added ⤵️ pull merge-conflict Resolve conflicts manually labels Apr 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⤵️ pull merge-conflict Resolve conflicts manually
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants