Set max-width-chars property in ibus-setup wrapped GtkLabel.

If GtkWindow has 'resizable' property = FALSE, the wrap in GtkLabel
is not done automatically and need to set 'max-width-chars' property.

TEST=ibus-setup

Review URL: https://codereview.appspot.com/92940043
Add the nodeadkeys variant of the German keyboard layout.

BUG=http://code.google.com/p/ibus/issues/detail?id=1710

Review URL: https://codereview.appspot.com/96040043
Patch from Eike Hein <hein@kde.org>.
Delete Korean keymap.

BUG=http://code.google.com/p/ibus/issues/detail?id=1708

Review URL: https://codereview.appspot.com/92090043
Patch from Ryu Changwoo <ryu.changwoo@gmail.com>.
Let ibus-ui-gtk3 not to show zero-lenght preedit text.

preedit text is shown by ibus-ui-gtk3 on X11 applications
and do not have to show it likes GTK+ when the lenght is zero.

BUG=http://code.google.com/p/ibus/issues/detail?id=1709
TEST=ibus-ui-gtk3 with ibus-pinyin and x11 applications

Review URL: https://codereview.appspot.com/93150043
build-sys: Fix 'privite' typo in Makefile.am

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/102140044
Patch from Christophe Fergeau <cfergeau@redhat.com>.
Fix small typo in gtk-doc API doc

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/108740043
Patch from Christophe Fergeau <cfergeau@redhat.com>.
Fix GVariant leaks

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/109720043
Patch from Christophe Fergeau <cfergeau@redhat.com>.
Fix string leaks in deserialize vfuncs

When an object contains char * properties, its deserialize function will
overwrite these string values without freeing them first. They are not
necessarily NULL as they can have (default) values set upon construction,
so they need to be g_free'd before being overwritten.

For example, IBusEngineDesc::longname, IBusEngineDesc::description,
IBusEngineDesc::language, ... are all set to "" upon construction (instead of
NULL), so the corresponding IBusEngineDesc fields must be freed before
being overwritten during deserialization.

This commit introduces a ibus_g_variant_get_child_string() to do this
and set the string value.

This leak was reported by valgrind:

==22163== 59 bytes in 59 blocks are definitely lost in loss record 1,633 of 2,720
==22163==    at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==22163==    by 0x56DFDF2: g_malloc (gmem.c:97)
==22163==    by 0x56E011D: g_malloc_n (gmem.c:338)
==22163==    by 0x56FAFCC: g_strdup (gstrfuncs.c:356)
==22163==    by 0x546CDB8: g_value_dup_string (gvaluetypes.c:1136)
==22163==    by 0x4E43A98: ibus_engine_desc_set_property (ibusenginedesc.c:385)
==22163==    by 0x5446CA3: object_set_property (gobject.c:1378)
==22163==    by 0x54484BB: g_object_constructor (gobject.c:2020)
==22163==    by 0x4E24564: ibus_object_constructor (ibusobject.c:111)
==22163==    by 0x5447577: g_object_new_with_custom_constructor (gobject.c:1645)
==22163==    by 0x5447787: g_object_new_internal (gobject.c:1722)
==22163==    by 0x5447C75: g_object_newv (gobject.c:1868)
==22163==    by 0x544737A: g_object_new (gobject.c:1568)
==22163==    by 0x4E2521C: ibus_serializable_deserialize (ibusserializable.c:292)
==22163==    by 0x4E480E0: ibus_component_deserialize (ibuscomponent.c:408)
==22163==    by 0x4E2523E: ibus_serializable_deserialize (ibusserializable.c:294)
==22163==    by 0x4E4C1D1: ibus_registry_deserialize (ibusregistry.c:202)
==22163==    by 0x4E4C95C: ibus_registry_load_cache_file (ibusregistry.c:362)
==22163==    by 0x4E4C6A4: ibus_registry_load_cache (ibusregistry.c:302)
==22163==    by 0x40EBCD: bus_ibus_impl_registry_init (ibusimpl.c:1871)
==22163==    by 0x40C1D4: bus_ibus_impl_init (ibusimpl.c:424)
==22163==    by 0x5460FCD: g_type_create_instance (gtype.c:1868)
==22163==    by 0x5448466: g_object_constructor (gobject.c:2006)
==22163==    by 0x4E24564: ibus_object_constructor (ibusobject.c:111)
==22163==    by 0x5447577: g_object_new_with_custom_constructor (gobject.c:1645)
==22163==    by 0x5447787: g_object_new_internal (gobject.c:1722)
==22163==    by 0x54483C1: g_object_new_valist (gobject.c:1980)
==22163==    by 0x54473C9: g_object_new (gobject.c:1571)
==22163==    by 0x40E94A: bus_ibus_impl_get_default (ibusimpl.c:1807)
==22163==    by 0x41D880: bus_server_init (server.c:100)
==22163==    by 0x420E91: main (main.c:236)

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/104850043
Patch from Christophe Fergeau <cfergeau@redhat.com>.
Fix g_dbus_proxy_get_name_owner() leaks

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/105830043
Patch from Christophe Fergeau <cfergeau@redhat.com>.
Fix GObject leaks in ibus_property_deserialize()

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/103100043
Patch from Christophe Fergeau <cfergeau@redhat.com>.
Fix GDBusNodeInfo leak in ibus_service_class_add_interfaces

A call to g_dbus_node_info_unref was in place but commented out.

This fixes:

==20039== 424 (40 direct, 384 indirect) bytes in 1 blocks are definitely lost in loss record 2,115 of 2,159
==20039==    at 0x4A081D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20039==    by 0x56ECE69: g_malloc0 (gmem.c:127)
==20039==    by 0x56ED191: g_malloc0_n (gmem.c:362)
==20039==    by 0x519FBF2: parse_data_get_node (gdbusintrospection.c:1171)
==20039==    by 0x519FFE1: parser_start_element (gdbusintrospection.c:1290)
==20039==    by 0x56E9C2E: emit_start_element (gmarkup.c:1048)
==20039==    by 0x56EA7CB: g_markup_parse_context_parse (gmarkup.c:1395)
==20039==    by 0x51A1082: g_dbus_node_info_new_for_xml (gdbusintrospection.c:1797)
==20039==    by 0x4E33D38: ibus_service_class_add_interfaces (ibusservice.c:610)
==20039==    by 0x4E32C24: ibus_service_class_init (ibusservice.c:213)
==20039==    by 0x546EE85: type_class_init_Wm (gtype.c:2220)
==20039==    by 0x5470586: g_type_class_ref (gtype.c:2935)
==20039==    by 0x5470539: g_type_class_ref (gtype.c:2927)
==20039==    by 0x5470539: g_type_class_ref (gtype.c:2927)
==20039==    by 0x5454D21: g_object_new_valist (gobject.c:1906)
==20039==    by 0x54543C9: g_object_new (gobject.c:1571)
==20039==    by 0x402AF0: ibus_config_dconf_new (config.c:449)
==20039==    by 0x401D59: ibus_dconf_start (main.c:61)
==20039==    by 0x401E30: main (main.c:85)
==20039==~

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/100990043
Patch from Christophe Fergeau <cfergeau@redhat.com>.
Fix leak in ibus-engine-switch test

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/104860043
Patch from Christophe Fergeau <cfergeau@redhat.com>.
tests/ibus-config: Fix typo in function name

"success" was misspelt "sucess"

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/102160043
Patch from Christophe Fergeau <cfergeau@redhat.com>.
Fix GVariantBuilder leaks

When using g_variant_builder_new(), we must call
g_variant_builder_unref() to free it:
"You should call g_variant_builder_unref() on the return value when it
is no longer needed. The memory will not be automatically freed by any
other call.

In most cases it is easier to place a GVariantBuilder directly on the
stack of the calling function and initialise it with
g_variant_builder_init()."

One of these leaks showed up in valgrind as:
==20702== 16,416 bytes in 114 blocks are definitely lost in loss record 2,114 of 2,115
==20702==    at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20702==    by 0x56EDDF2: g_malloc (gmem.c:97)
==20702==    by 0x570691C: g_slice_alloc (gslice.c:1007)
==20702==    by 0x5729743: g_variant_builder_new (gvariant.c:3169)
==20702==    by 0x40297B: ibus_config_dconf_get_values (config.c:413)
==20702==    by 0x4E44FF2: ibus_config_service_service_method_call (ibusconfigservice.c:214)
==20702==    by 0x4E33249: ibus_service_service_method_call_cb (ibusservice.c:395)
==20702==    by 0x51880D8: call_in_idle_cb (gdbusconnection.c:4875)
==20702==    by 0x56E81D7: g_idle_dispatch (gmain.c:5319)
==20702==    by 0x56E58F1: g_main_dispatch (gmain.c:3064)
==20702==    by 0x56E6667: g_main_context_dispatch (gmain.c:3663)
==20702==    by 0x56E6859: g_main_context_iterate (gmain.c:3734)

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/104850044
Patch from Christophe Fergeau <cfergeau@redhat.com>.
dconf: Fix GVariant refcounting in watch_func()

IBusConfigDConf::watch_func() is roughly doing:
GVariant *variant = dconf_client_read(...)
if (variant == NULL) {
    variant = g_variant_new(...);
}
ibus_config_service_value_changed(..., variant);
g_variant_unref(variant);

The problem with that is that the GVariant returned by
dconf_client_read() is non-floating while the one returned by
g_variant_new() is floating.
Since ibus_config_service_value_changed() will take ownership of
floating references, we should not unref 'variant' if it was created
through g_variant_new(), but we must call it when 'variant' is created
through dconf_client_read() or we will leak memory.

This commit fixes that by making sure we sink the reference we got
through g_variant_new().

This was sometimes causing crashes of ibus-dconf when repeatedly running
tests/ibus-config:

(ibus-dconf:24679): GLib-CRITICAL **: g_variant_unref: assertion
'value->ref_count > 0' failed

==24679== Invalid read of size 4
==24679==    at 0x572E140: g_variant_unref (gvariant-core.c:625)
==24679==    by 0x572DBB3: g_variant_release_children (gvariant-core.c:257)
==24679==    by 0x572E202: g_variant_unref (gvariant-core.c:640)
==24679==    by 0x572DBB3: g_variant_release_children (gvariant-core.c:257)
==24679==    by 0x572E202: g_variant_unref (gvariant-core.c:640)
==24679==    by 0x518CFDE: g_dbus_message_finalize (gdbusmessage.c:534)
==24679==    by 0x5459628: g_object_unref (gobject.c:3112)
==24679==    by 0x519C911: message_to_write_data_free (gdbusprivate.c:898)
==24679==    by 0x519D687: write_message_cb (gdbusprivate.c:1353)
==24679==    by 0x510F7F2: g_simple_async_result_complete (gsimpleasyncresult.c:763)
==24679==    by 0x519CEF2: write_message_continue_writing (gdbusprivate.c:1077)
==24679==    by 0x519D040: write_message_async (gdbusprivate.c:1131)
==24679==  Address 0x5d8c9c4 is 36 bytes inside a block of size 40 free'd
==24679==    at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24679==    by 0x56EDF6B: g_free (gmem.c:190)
==24679==    by 0x5706B53: g_slice_free1 (gslice.c:1112)
==24679==    by 0x572E229: g_variant_unref (gvariant-core.c:643)
==24679==    by 0x40240F: _watch_func (config.c:232)
==24679==    by 0x3DEA605D8B: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.1)
==24679==    by 0x3DEA6056BB: ffi_call (in /usr/lib64/libffi.so.6.0.1)
==24679==    by 0x544EE88: g_cclosure_marshal_generic_va (gclosure.c:1541)
==24679==    by 0x544D396: _g_closure_invoke_va (gclosure.c:831)
==24679==    by 0x5468808: g_signal_emit_valist (gsignal.c:3215)
==24679==    by 0x54699DF: g_signal_emit (gsignal.c:3363)
==24679==    by 0x4C1478D: dconf_client_dispatch_change_signal (dconf-client.c:150)

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/107800044
Patch from Christophe Fergeau <cfergeau@redhat.com>.
Return non-floating ref from IBusConfigGConf::get_value

Both IBusConfigDConf::get_value and IBusConfigMemconf::get_value
return a non-floating reference, so we need to be consistent in the
gconf backend and also return a non-floating reference.

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/106830043
Patch from Christophe Fergeau <cfergeau@redhat.com>.
Fix GVariant leak in IBusService::SetValue

When handling the DBus SetValue call,
ibusconfigservice.c:ibus_config_service_service_method_call()
gets a GVariant through g_variant_get("(&s&sv)")
GVariant documentation says that:
« Upon encountering a 'v', g_variant_get() takes a pointer to a
(GVariant *) (ie: (GVariant **) ). It is set to a new reference to a
GVariant instance containing the contents of the variant value. It is
appropriate to free this reference using g_variant_unref(). »
so we need to unreference it when we are done with it.

Running ibus-dconf in valgrind and then running tests/ibus-config
shows this leak:

==28085== 3,934 (1,520 direct, 2,414 indirect) bytes in 38 blocks are definitely lost in loss record 2,112 of 2,121
==28085==    at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28085==    by 0x56EDDF2: g_malloc (gmem.c:97)
==28085==    by 0x570691C: g_slice_alloc (gslice.c:1007)
==28085==    by 0x572E6D9: g_variant_get_child_value (gvariant-core.c:1009)
==28085==    by 0x57261C0: g_variant_get_variant (gvariant.c:715)
==28085==    by 0x572BD03: g_variant_valist_get_nnp (gvariant.c:4794)
==28085==    by 0x572C3F1: g_variant_valist_get_leaf (gvariant.c:4911)
==28085==    by 0x572CAD4: g_variant_valist_get (gvariant.c:5092)
==28085==    by 0x572CC59: g_variant_valist_get (gvariant.c:5127)
==28085==    by 0x572D079: g_variant_get_va (gvariant.c:5354)
==28085==    by 0x572CF9B: g_variant_get (gvariant.c:5301)
==28085==    by 0x4E44E5B: ibus_config_service_service_method_call (ibusconfigservice.c:173)

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/108740044
Patch from Christophe Fergeau <cfergeau@redhat.com>.
Fix GVariant leak in IBusService::GetValue

When handling the DBus GetValue call,
ibusconfigservice.c:ibus_config_service_service_method_call()
gets a non-floating GVariant reference through
IBusConfigService::get_value() but never unrefs it.

Running ibus-dconf in valgrind and then running tests/ibus-config
shows this leak:

=28085== 232 (80 direct, 152 indirect) bytes in 2 blocks are definitely lost in loss record 2,025 of 2,121
==28085==    at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28085==    by 0x56EDDF2: g_malloc (gmem.c:97)
==28085==    by 0x570691C: g_slice_alloc (gslice.c:1007)
==28085==    by 0x572E6D9: g_variant_get_child_value (gvariant-core.c:1009)
==28085==    by 0x57261C0: g_variant_get_variant (gvariant.c:715)
==28085==    by 0x4C1A732: gvdb_table_value_from_item (gvdb-reader.c:578)
==28085==    by 0x4C1A7A1: gvdb_table_get_value (gvdb-reader.c:610)
==28085==    by 0x4C1589C: dconf_engine_read (dconf-engine.c:528)
==28085==    by 0x4C14A79: dconf_client_read (dconf-client.c:242)
==28085==    by 0x40286F: ibus_config_dconf_get_value (config.c:378)
==28085==    by 0x4E44F29: ibus_config_service_service_method_call (ibusconfigservice.c:194)
==28085==    by 0x4E33249: ibus_service_service_method_call_cb (ibusservice.c:395)

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/103100045
Patch from Christophe Fergeau <cfergeau@redhat.com>.
Add Polish (qwertz) keymap in simple.xml

BUG=http://code.google.com/p/ibus/issues/detail?id=1716
TEST=ibus-setup

Review URL: https://codereview.appspot.com/102150045
tests/ibus-config Fix timeout_id handling

tests/ibus-config queues a timeout whose callback calls
g_main_loop_quit() before returning FALSE. After exiting the mainloop,
g_source_remove(timeout_id) is called, but if the mainloop was exited
through the timeout callback, the source will already have been removed.

This commit makes sure we only try to call g_source_remove() on that
timeout if we did not exit the mainloop through the timeout callback.

BUG=http://code.google.com/p/ibus/issues/detail?id=1712

Review URL: https://codereview.appspot.com/108730044
Patch from Christophe Fergeau <cfergeau@redhat.com>.