Add non-trivial IBus engines such as transliteration based ones.
Though these engines have not yet confirmed by local language
users, it would be probably safe to leave them.
https://bugzilla.gnome.org/show_bug.cgi?id=683697
wubi and erbi (both from ibus-table) are popular stroke based input
methods for inputing Simplified Chinese and Traditional Chinese.
A local user said that wubi covers at least 20% of the Simplified
Chinese users. erbi is similar to wubi and getting popular because
of easiness to learn.
https://bugzilla.gnome.org/show_bug.cgi?id=683697
The Format: row was being pushed to the bottom, and when the
input sources value was longer on the one side than the other,
the horizontal alignment was broken.
Unfortunately we don't have a way yet to make gsettings system wide
defaults so we are just using the localed API to export the XKB input
sources and ignore the IBus ones.
https://bugzilla.gnome.org/show_bug.cgi?id=683875
ibus_engine_desc_get_language() may return an empty string or language
codes that gdm_get_language_from_name() doesn't understand. Use
ibus_get_language_name() instead to handle such cases properly.
This also allows us to use the same method in gnome-shell to get
consistent display strings.
https://bugzilla.gnome.org/show_bug.cgi?id=682851
In fallback mode we don't want to touch IBus since the gnome-shell UI
isn't there to provide the full integrated user experience.
We expect users to continue using existing IBus UIs in fallback mode.
https://bugzilla.gnome.org/show_bug.cgi?id=682864
When the going from the region panel to the overview and back,
the input methods in the list loose their display names. What
is happening is that we recreate the ibus object, but the second
time around it is already connected since ibus uses a shared
singleton connection internally. Thus, the ::connected signal
is never emitted, and we don't fetch the engines.
Work around this by checking if the newly created ibus object
is already connected, and directly calling fetch_ibus_engines
if it is. To make this work, we have to set up the treeview
with its model earlier.
update_ibus_active_sources may very well be called with
an empty treeview. The code that iterates over the model
was assuming that there is at least one item. Fix that
by checking the return value of gtk_tree_model_get_iter_first().
When the active input sources list is changed in any way (add or
remove or reorder a source), we write the list to the setting,
and then we get a changed signal for the setting, and rebuild
the list from the setting. Doing so loses the selection, unless
we take extra precaution to keep it.
https://bugzilla.gnome.org/show_bug.cgi?id=680027
There was some code left around for dealing with a filter model,
but we don't have the active input sources in a filtered list
anymore. This was leading to crashes when removing or rearranging
input sources.
When modifying the input sources list the currently active source's
index might change. We must change the current setting accordingly to
keep it active.
https://bugzilla.gnome.org/show_bug.cgi?id=662489
Unref the GSettings object and build the GnomeXkbInfo only
once. There's no need to free and keep rebuilding the latter since it
doesn't keep any state and is a bit expensive to build.
https://bugzilla.gnome.org/show_bug.cgi?id=662489
If IBus is unavailable to get the input source's display name,
just show the ID instead, and populate the display name when we get
a change (eg. when fetching the input sources from IBus is done).
For XKB input sources the settings button remains unsensitive. For
IBus sources we make it sensitive and launch the engine's setup tool
on clicked if there is one.
https://bugzilla.gnome.org/show_bug.cgi?id=662489
This makes the dialog return when the user presses Enter on the filter
entry and prevents the GtkTreeView search popup from being used since
we already handle searching on that tree view.
https://bugzilla.gnome.org/show_bug.cgi?id=662489
Instead of splitting the list of layouts into layouts and variants,
we were expecting strings of the form:
layout1 variant1, layout2 variant2
to be handled automatically. We should instead create the lists
of layouts and variants separately before passing them to localed.
https://bugzilla.gnome.org/show_bug.cgi?id=670607
When enabled, "extra" layouts are rendered as italic.
It was broken, the markup was visible literally - now it is real italic text
Signed-off-by: Sergey V. Udaltsov <svu@gnome.org>