After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 702344 - common-language: fix languages in the user panel
common-language: fix languages in the user panel
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: User Accounts
unspecified
Other All
: Normal normal
: ---
Assigned To: Ondrej Holy
Control-Center Maintainers
3.10
: 702168 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-06-15 15:30 UTC by Giovanni Campagna
Modified: 2013-07-25 10:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
common-language: fix languages in the user panel (3.90 KB, patch)
2013-06-15 15:30 UTC, Giovanni Campagna
reviewed Details | Review
common: ensure the current language has a display name in the model (1.57 KB, patch)
2013-06-26 15:02 UTC, Thomas Wood
committed Details | Review

Description Giovanni Campagna 2013-06-15 15:30:34 UTC
add_user_languages() was expected to add all languages currently
in use in the system, but instead added only the default ones,
meaning that the active one was sometimes missing.
Comment 1 Giovanni Campagna 2013-06-15 15:30:38 UTC
Created attachment 246895 [details] [review]
common-language: fix languages in the user panel
Comment 2 Rui Matos 2013-06-15 20:32:47 UTC
Review of attachment 246895 [details] [review]:

The changes in get_lang_for_user_object_path() are only a clean-up to not instantiate GBusProxy instances, right? They should go a different patch then.

::: panels/common/cc-common-language.c
@@ +743,2 @@
         /* Add the current locale first */
         name = cc_common_language_get_current_language ();

Hmm, this call here is supposed to add the current language to the initial set. In fact get_user_languages() calls get_current_language() internally.

More generally I'm not sure if we should change the behavior unconditionally, since there's the potential for the initial list to get too big while the design specifically calls for a small initial list.
Comment 3 Giovanni Campagna 2013-06-16 13:04:18 UTC
(In reply to comment #2)
> Review of attachment 246895 [details] [review]:
> 
> The changes in get_lang_for_user_object_path() are only a clean-up to not
> instantiate GBusProxy instances, right? They should go a different patch then.
> 
> ::: panels/common/cc-common-language.c
> @@ +743,2 @@
>          /* Add the current locale first */
>          name = cc_common_language_get_current_language ();
> 
> Hmm, this call here is supposed to add the current language to the initial set.
> In fact get_user_languages() calls get_current_language() internally.

get_current_language(), as the name implies, returns the current language, without affecting external state. I don't see how it could add that to the initial set.

> More generally I'm not sure if we should change the behavior unconditionally,
> since there's the potential for the initial list to get too big while the
> design specifically calls for a small initial list.

I hope you're not implying that we should leave the user with an empty combobox in the user page just because it could get too big.
Comment 4 Rui Matos 2013-06-16 13:53:21 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Hmm, this call here is supposed to add the current language to the initial set.
> > In fact get_user_languages() calls get_current_language() internally.
> 
> get_current_language(), as the name implies, returns the current language,
> without affecting external state. I don't see how it could add that to the
> initial set.

Ah, sorry, I misread.

> > More generally I'm not sure if we should change the behavior unconditionally,
> > since there's the potential for the initial list to get too big while the
> > design specifically calls for a small initial list.
> 
> I hope you're not implying that we should leave the user with an empty combobox
> in the user page just because it could get too big.

No I'm not. I'm saying that adding all the user accounts languages without a limit (say, at most 5) has the potential to make the list too big. Admittedly, this would be an highly unlikely scenario.

Anyway, I'd say that we should just add the current users' language (of course, so that the combobox doesn't have an empty item) since we're already adding the "common" ones too and there are already 9 of those.

For any further changes I'd like to hear a designer's opinion. Actually, to me, this combobox doesn't even make much sense since the language is something you configure in another panel already.
Comment 5 Rui Matos 2013-06-16 13:53:54 UTC
*** Bug 702168 has been marked as a duplicate of this bug. ***
Comment 6 Thomas Wood 2013-06-26 15:02:22 UTC
Created attachment 247836 [details] [review]
common: ensure the current language has a display name in the model

This is a slightly simpler patch that just ensures the current language is
present in the list of initial languages and therefore has a display name when
added to the model.
Comment 7 Rui Matos 2013-06-28 12:56:04 UTC
Review of attachment 247836 [details] [review]:

Didn't test but seems fine. Push to 3.8 too
Comment 8 Thomas Wood 2013-06-28 14:55:06 UTC
Comment on attachment 247836 [details] [review]
common: ensure the current language has a display name in the model

Attachment 247836 [details] pushed as 0221ffe - common: ensure the current language has a display name in the model