Remove block call in ibus-daemon, and use async call instead and clean up code.

Remove block call in ibus-daemon, and use async call instead and clean up code.

1. Do not use poll factory of a component. Sometime, it will cause a dead lock of ibus: ibus-daemon are waiting reply from engine, and engine are also waiting for reply from ibus-daemon.
2. Move some API from IBusComponent to BusComponent, Because of those API is for internal using only
3. Add a fake input context in server side to support switching input method when no context has focus.
4. Remove fake input context in imcontext, because we added the server side fake context

BUG=none
TEST=manual

[Yusuke Sato, 2010-11-15 08:35:02]

LGTM. Let's just submit it for now (after fixing some nits below). I'll take a
closer look when I add comments to the files.

One request: could you add a comment to the CL description about the motivation
of this CL. It's a little bit unclear for me why you wrote this change.

http://codereview.appspot.com/3077042/diff/1/bus/factoryproxy.c
File bus/factoryproxy.c (right):

http://codereview.appspot.com/3077042/diff/1/bus/factoryproxy.c#newcode73
bus/factoryproxy.c:73: #if 0
Please add a brief comment like:
/* Remove bus_factory_proxy_create_engine function later */
or something.

http://codereview.appspot.com/3077042/diff/1/bus/factoryproxy.h
File bus/factoryproxy.h (right):

http://codereview.appspot.com/3077042/diff/1/bus/factoryproxy.h#newcode55
bus/factoryproxy.h:55: #if 0
Let's just remove the line 55-58 to keep the code clean.

http://codereview.appspot.com/3077042/diff/1/bus/ibusimpl.c
File bus/ibusimpl.c (right):

http://codereview.appspot.com/3077042/diff/1/bus/ibusimpl.c#newcode128
bus/ibusimpl.c:128: static void     bus_ibus_impl_add_component   (BusIBusImpl  
     *ibus,
can we remove this?

http://codereview.appspot.com/3077042/diff/1/bus/ibusimpl.c#newcode614
bus/ibusimpl.c:614: (void)bus_registry_name_owner_changed (ibus->registry, name,
old_name, new_name);
nit: remove (void) ?

http://codereview.appspot.com/3077042/diff/1/bus/ibusimpl.c#newcode777
bus/ibusimpl.c:777: #if 0
How about adding a comment like:
/* Remove _timeout_cb, _get_factory_proxy, and bus_ibus_impl_create_engine
functions later. */

http://codereview.appspot.com/3077042/diff/1/bus/ibusimpl.c#newcode1528
bus/ibusimpl.c:1528: 5000,
nit: you used 5000 twice. how about define global static const variable?

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.c
File src/ibuscomponent.c (right):

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.c#newcode227
src/ibuscomponent.c:227: component->priv->pid = 0;
please remove line 227 and 228.

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.c#newcode238
src/ibuscomponent.c:238: component->priv->verbose = FALSE;
ditto. please remove 238 and 239.

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.h
File src/ibuscomponent.h (right):

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.h#newcode99
src/ibuscomponent.h:99: gpointer pdummy[7];  // We can add 5 pointers without
breaking the ABI.
nit: the array size and the comment don't match.
nit: is 7 correct? looks like you removed 4 members.

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.h#newcode310
src/ibuscomponent.h:310: #if 0
why #if 0?

http://codereview.appspot.com/3077042/diff/1/src/ibusconfig.h
File src/ibusconfig.h (right):

http://codereview.appspot.com/3077042/diff/1/src/ibusconfig.h#newcode116
src/ibusconfig.h:116: * ibus_config_get_value_async:
Looks like a nice way (to workaround the process start-up issue we saw in the
chromeos branch,) but I have a (silly) question:

What happens if we call the api in this way?

ibus_config_get_value_async("A");
ibus_config_get_value_async("B");
ibus_config_get_value_async_finish();  // which is returned? A or B

[Peng, 2010-11-16 01:14:58]

http://codereview.appspot.com/3077042/diff/1/bus/factoryproxy.c
File bus/factoryproxy.c (right):

http://codereview.appspot.com/3077042/diff/1/bus/factoryproxy.c#newcode73
bus/factoryproxy.c:73: #if 0
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> Please add a brief comment like:
> /* Remove bus_factory_proxy_create_engine function later */
> or something.
> 

Done.

http://codereview.appspot.com/3077042/diff/1/bus/factoryproxy.h
File bus/factoryproxy.h (right):

http://codereview.appspot.com/3077042/diff/1/bus/factoryproxy.h#newcode55
bus/factoryproxy.h:55: #if 0
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> Let's just remove the line 55-58 to keep the code clean.

Done.

http://codereview.appspot.com/3077042/diff/1/bus/ibusimpl.c
File bus/ibusimpl.c (right):

http://codereview.appspot.com/3077042/diff/1/bus/ibusimpl.c#newcode128
bus/ibusimpl.c:128: static void     bus_ibus_impl_add_component   (BusIBusImpl  
     *ibus,
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> can we remove this?
I removed _add_commponent, and think we could keep the set and get property
function. I plan to use it to replace some getter and setter function in future

http://codereview.appspot.com/3077042/diff/1/bus/ibusimpl.c#newcode128
bus/ibusimpl.c:128: static void     bus_ibus_impl_add_component   (BusIBusImpl  
     *ibus,
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> can we remove this?

Done.

http://codereview.appspot.com/3077042/diff/1/bus/ibusimpl.c#newcode614
bus/ibusimpl.c:614: (void)bus_registry_name_owner_changed (ibus->registry, name,
old_name, new_name);
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> nit: remove (void) ?

I am not sure if it will cause warning when compile with -Wall

http://codereview.appspot.com/3077042/diff/1/bus/ibusimpl.c#newcode614
bus/ibusimpl.c:614: (void)bus_registry_name_owner_changed (ibus->registry, name,
old_name, new_name);
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> nit: remove (void) ?

Done.

http://codereview.appspot.com/3077042/diff/1/bus/ibusimpl.c#newcode777
bus/ibusimpl.c:777: #if 0
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> How about adding a comment like:
> /* Remove _timeout_cb, _get_factory_proxy, and bus_ibus_impl_create_engine
> functions later. */

Done.

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.c
File src/ibuscomponent.c (right):

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.c#newcode227
src/ibuscomponent.c:227: component->priv->pid = 0;
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> please remove line 227 and 228.

Done.

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.c#newcode238
src/ibuscomponent.c:238: component->priv->verbose = FALSE;
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> ditto. please remove 238 and 239.

Done.

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.h
File src/ibuscomponent.h (right):

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.h#newcode99
src/ibuscomponent.h:99: gpointer pdummy[7];  // We can add 5 pointers without
breaking the ABI.
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> nit: the array size and the comment don't match.
> nit: is 7 correct? looks like you removed 4 members.

Done.

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.h#newcode310
src/ibuscomponent.h:310: #if 0
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> why #if 0?
I think this function is not necessary anymore. So remove it.

http://codereview.appspot.com/3077042/diff/1/src/ibuscomponent.h#newcode310
src/ibuscomponent.h:310: #if 0
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> why #if 0?

Done.

http://codereview.appspot.com/3077042/diff/1/src/ibusconfig.h
File src/ibusconfig.h (right):

http://codereview.appspot.com/3077042/diff/1/src/ibusconfig.h#newcode116
src/ibusconfig.h:116: * ibus_config_get_value_async:
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> Looks like a nice way (to workaround the process start-up issue we saw in the
> chromeos branch,) but I have a (silly) question:
> 
> What happens if we call the api in this way?
> 
> ibus_config_get_value_async("A");
> ibus_config_get_value_async("B");
> ibus_config_get_value_async_finish();  // which is returned? A or B

When you call _get_value_async, you should provide a callback function. You have
to call finish function in the callback function, and pass the GAsyncResult to
_finish. The GAsyncResult know which value should be returned.

http://codereview.appspot.com/3077042/diff/1/src/ibusconfig.h#newcode116
src/ibusconfig.h:116: * ibus_config_get_value_async:
On 2010/11/15 08:35:02, Yusuke Sato wrote:
> Looks like a nice way (to workaround the process start-up issue we saw in the
> chromeos branch,) but I have a (silly) question:
> 
> What happens if we call the api in this way?
> 
> ibus_config_get_value_async("A");
> ibus_config_get_value_async("B");
> ibus_config_get_value_async_finish();  // which is returned? A or B

Done.