Created attachment 225734 [details] [review]
keyboard: Slight refactoring for upcoming changes

We're going to add some special handling that doesn't apply when
running under GDM so return early if that's the case.

Created attachment 225735 [details] [review]
keyboard: Add likely IBus engine for some locales if empty setting

If there are no input sources configured and we're running under one
of some specific locales where it's highly likely that the user will
need/want a specific IBus source to type we just add it to the list.

LC_CTYPE is used to determine the locale for this purpose since many
users in these locales set LC_MESSAGES to English.

Created attachment 225737 [details] [review]
keyboard: Add likely IBus engine for some locales if empty setting

--
Added zh_TW → chewing

Can't the locale_engine list be unified with the supported_engines list in g-c-c somehow?  I expect that they will soon have several duplicates and maintaining them in two places would be cumbersome.

I also think the initial trigger key is Ctrl+space for CJKI users.

Review of attachment 225734 [details] [review]:

++

::: plugins/keyboard/gsd-keyboard-manager.c
@@ +1318,2 @@
+        sources = g_settings_get_value (settings, KEY_INPUT_SOURCES);
+        if (g_variant_n_children (sources) < 1) {

No curlies here.

Review of attachment 225737 [details] [review]:

::: plugins/keyboard/gsd-keyboard-manager.c
@@ +520,3 @@
+                { "zh_CN", "pinyin" },
+                { "zh_HK", "cangjie3" },
+                { "zh_TW", "chewing" },

Are those really all the locales we can handle?
Can you add a reference to where you found this magic?

@@ +1346,2 @@
 static void
+init_builder_with_sources (GVariantBuilder *builder,

Move this up so you don't need to declare it. And is it used when building without ibus support?

(In reply to comment #5)
> I also think the initial trigger key is Ctrl+space for CJKI users.

Separate bug I think. See bug 682319.

Actually, can't we do that as well? Language-specific defaults translated by the translators...

(In reply to comment #8)
> Actually, can't we do that as well? Language-specific defaults translated by
> the translators...

I'm not sure this would work because, AFAIK, translations are determined from LC_MESSAGES and that's not an optimal way to do these defaults as I was told that a lot of people prefer en_US for LC_MESSAGES.

And anyway, I'd like to see this code going away soon rather than late when we get the initial setup story straight because that's the place where the user should be choosing this kind of thing for a newly created account. So, I regard this as a temporary painkiller only.

(In reply to comment #4)
> Can't the locale_engine list be unified with the supported_engines list in
> g-c-c somehow?  I expect that they will soon have several duplicates and
> maintaining them in two places would be cumbersome.

See comment #9 - this is only a temporary thing until initial setup is ready.

Created attachment 225813 [details] [review]
keyboard: Slight refactoring for upcoming changes

--
Removed curlies.

Created attachment 225815 [details] [review]
keyboard: Add likely IBus engine for some locales if empty setting

--

(In reply to comment #7)
> Are those really all the locales we can handle?

This are the obvious ones for me. I'm always sort of expecting that
local users will contribute with their opinion for these things...

> Can you add a reference to where you found this magic?

For ja_JP and ko_KR, those are the only ones available, for the others
I used Mathieu's awesome writeup[1] and an hint on IRC. Since this
should go way for 3.8 I don't think it's worth it to make it much more
sophisticated.

[1] http://bochecha.fedorapeople.org/chinese_ims/

> @@ +1346,2 @@
>  static void
> +init_builder_with_sources (GVariantBuilder *builder,
>
> Move this up so you don't need to declare it. And is it used when building
> without ibus support?

That was because I was trying to keep the code slinging at a minimum
taking into account the other patch for converting old settings which
also uses this. But moving code is cheap so, ack.

Review of attachment 225815 [details] [review]:

++

Attachment 225813 [details] pushed as c33ff6c - keyboard: Slight refactoring for upcoming changes
Attachment 225815 [details] pushed as 2c1f886 - keyboard: Add likely IBus engine for some locales if empty setting

I was expecting this works for new user account at least but seems not working in some case. I tried the following steps once removing an user and create one:

Test case 1:
1. Log in with Japanese
2. Look at the input source selector at the panel

Result 1:
No input source for ibus-anthy

Test case 2:
1. Log in with Japanese
2. Look at the input source selector at the panel
3. Log out
4. Log in and look at the input source

Result 2:
No input source for ibus-anthy

Test case 3:
1. Log in with Japanese
2. Look at the input source selector at the panel
3. Open Region and Language at the System Settings
4. wait for a while...

Result 3:
No input source for ibus-anthy at the panel but it appears on R&L window after waiting for a minute or so.

Test case 4:
1. Log in with Japanese
2. Look at the input source selector at the panel
3. Log out
4. Log in and open Region and Language at the System Settings
5. wait for a while...

Result 4:
No input source for ibus-anthy even though waiting for some time.


As per the above results, it looks like opening R&L window is a trigger to be added the default engine. I'm not sure if it's expected behavior, but that would be nice if g-s-d can adds one without any extra operation.

Hmm, it's a bit laggy. no relevant to R&L window at all. sorry for confusion.