GNOME Bugzilla – Bug 699501
Have a guess at an appropriate input method
Last modified: 2013-05-10 16:44:42 UTC
When you load the input method selection page maybe we could take a guess at the input you may want by looking at the language. Something like: diff --git a/gnome-initial-setup/pages/keyboard/gis-keyboard-page.c b/gnome-initial-setup/pages/keyboard/gis-keyboard-page.c index 2e6490a..947566b 100644 --- a/gnome-initial-setup/pages/keyboard/gis-keyboard-page.c +++ b/gnome-initial-setup/pages/keyboard/gis-keyboard-page.c @@ -149,10 +149,14 @@ gis_keyboard_page_get_builder (GisPage *page) return priv->builder; } +static void add_input_sources_guess (GisKeyboardPage *page); + static void gis_keyboard_page_locale_changed (GisPage *page) { gis_page_set_title (GIS_PAGE (page), _("Input Sources")); + + add_input_sources_guess (GIS_KEYBOARD_PAGE (page)); } static void @@ -685,6 +689,39 @@ input_source_already_added (GisKeyboardPage *self, } static void +add_input_sources_guess (GisKeyboardPage *self) +{ + GisKeyboardPagePrivate *priv = self->priv; + GVariant *sources; + const gchar *type; + const gchar *lang_id = gis_driver_get_user_language (GIS_PAGE (self)->driver); + if (!lang_id) + return; + + /* turns "en_GB.utf8" into "gb" */ + gchar **langa = g_strsplit (lang_id, "_", 2); + gchar **langb = g_strsplit (langa[1], ".", 2); + gchar *lang = g_ascii_strdown (langb[0], -1); + + if (input_source_already_added (self, lang)) + goto out; + + sources = g_variant_new_parsed ("[(%s,%s)]",INPUT_SOURCE_TYPE_XKB, lang); + + add_input_sources (self, sources); + update_buttons (self); + update_input (self); + + g_variant_unref (sources); + +out: + g_free (lang); + g_strfreev (langa); + g_strfreev (langb); +} + +static void input_response (GtkWidget *chooser, gint response_id, gpointer data) { GisKeyboardPage *self = data; I'm not sure what the IBUS/XKB implications are here. It does work for me though.
Created attachment 243707 [details] [review] keyboard: Remove more unused code We are not making use of any this code for now.
Created attachment 243708 [details] [review] keyboard: Populate input sources from localed initially Since gnome-initial-setup is supposed to be run only for new user accounts it should get the initial list of input sources from the keyboard layouts configured system wide.
Created attachment 243709 [details] [review] keyboard: Initialize our private variables in constructed This gets us more in line with other pages and allows us to use the 'driver' construct property later.
Created attachment 243710 [details] [review] keyboard: Use GisPage's common code to load the .ui resource No point in rolling our own.
Created attachment 243711 [details] [review] language: Set the driver user language on contruction Other pages would get NULL if they tried to get the language before the user changed it at least once.
Created attachment 243712 [details] [review] keyboard: Factor out add_input_source method We'll need to use it elsewhere.
Created attachment 243713 [details] [review] keyboard: Add a default input source for the locale Using this API from gnome-desktop we can get a good default input source for the user chosen locale.
Ok, this patch set cleans up a few things and then adds a way to set a default input source based on the API that was added in gnome-desktop for 3.8.
Review of attachment 243707 [details] [review]: OK.
Review of attachment 243708 [details] [review]: OK.
Review of attachment 243709 [details] [review]: OK.
Review of attachment 243710 [details] [review]: OK.
Review of attachment 243711 [details] [review]: Hm. What language would this choose by default? The current language? Should we instead ignore NULLs in future pages, or set it to the current language in the driver?
Review of attachment 243712 [details] [review]: Sure.
Review of attachment 243713 [details] [review]: OK.
(In reply to comment #13) > Review of attachment 243711 [details] [review]: > > Hm. What language would this choose by default? The current language? It gets the language determined by cc_common_language_get_current_language() which is whatever is in AccountsService for the current user. If the property isn't set there yet it falls back to LC_MESSAGES. > Should we > instead ignore NULLs in future pages, or set it to the current language in the > driver? As you can see in the last patch here, I need to use this to determine a default input source so I need a valid value from the start. This seemed like an easy way to get it but I'm open to other options.
(In reply to comment #16) > As you can see in the last patch here, I need to use this to determine a > default input source so I need a valid value from the start. This seemed like > an easy way to get it but I'm open to other options. I'm not overly happy with having the language page do initialization code. Having it in the driver seems more like the right place for me.
Created attachment 243729 [details] [review] driver: Initialize user language Some pages might want to query it and would get NULL if they tried before the user changed it at least once. -- Ok, this works for me.
Review of attachment 243729 [details] [review]: Yeah, I like this a lot better.
Attachment 243712 [details] pushed as 5de6cb5 - keyboard: Factor out add_input_source method Attachment 243713 [details] pushed as 136d1c6 - keyboard: Add a default input source for the locale Attachment 243729 [details] pushed as d7e40ff - driver: Initialize user language