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 501725 - Use24clock setting is ignored
Use24clock setting is ignored
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
2.20.x
Other Linux
: Normal minor
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2007-12-05 12:49 UTC by Josselin Mouette
Modified: 2008-04-29 01:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
patch fixing problem (2.86 KB, patch)
2008-04-29 01:11 UTC, Brian Cameron
none Details | Review

Description Josselin Mouette 2007-12-05 12:49:23 UTC
Initial report: http://bugs.debian.org/454245 by Kazuhiro NISHIYAMA

It looks like the GDM greeter ignores the Use24clock setting in gdm.conf. Only the current locale’s default is taken into consideration.

Furthermore, when changing this default with gdmsetup, the translated string is written to gdm.conf. For example, if in French locale I choose “non”, the recorded setting is “Use24clock=non” instead of “Use24clock=no”.
Comment 1 Brian Cameron 2007-12-05 22:18:55 UTC
Note that this bug was also reported in bug #449735, which says:

  2. Use24HrClock list selection does not display correct config values. auto and
  yes are both being displayed as auto

I'd be happy to accept a patch that fixes this problem.  Note that there is a patch in the other bug which fixes this, but this part of the patch would need to be extracted since that patch fixed a bunch of things that never made it into the 2.20 branch.
Comment 2 Brian Cameron 2007-12-10 20:31:03 UTC
I think the issue mentioned in #2 is already fixed in gdmsetup.  Looking at the patch, it seems gdmsetup was using CLOCK_AUTO for both "auto" and "yes".  This seems to be fixed now.  

Looking at the gdmgreeter code, it looks like greeter_item_udpate_text is calling gdm_common_expand_text.  It looks like any %c in the string should expand using gdm_common_get_clock, which calls gdm_common_select_time_format to get the value from the configuration setting.

If the configuration setting begins with T, t, Y, or y then it should use 24 hour clock.  If the configuration setting begins with F, f, N, or n then it should not use 24 hour clock.   If the configuration setting begins with anything else, then it will default to the system setting.

Perhaps the problem is that it is putting translated strings into the configuration file?  You say that for the negative value it puts "non" which should be recognized as a false setting.  But perhaps the positive setting doesn't begin with T|t|Y|y?  This might cause the problem you are seeing.

I'd say the problem is in the gui/gdmsetup.c file in the function combobox_timeout.  It looks like it just puts the "new_val" setting into the configuration file.  It probably should be changed to something like:

                if (new_val &&
                    strcmp (ve_sure_string (val), ve_sure_string (new_val)) != 0
) {
                        if (strcmp (_(new_val), _("auto"))
                           gdm_setup_config_set_string (key, "auto");
                        else if (strcmp (_(new_val), _("yes"))
                           gdm_setup_config_set_string (key, "true");
                        else
                           gdm_setup_config_set_string (key, "false");
                }

Does changing the code like this fix the problem?  That should ensure that the
English values get put into the configuration file rather than the translated
string.

If this works, could you attach a patch and I'll commit it to the 2.20 branch.

Comment 3 Brian Cameron 2008-04-29 01:11:25 UTC
Created attachment 110076 [details] [review]
patch fixing problem


I just applied the attached patch which I think is a lot smarter about ensuring that translated strings don't get saved into the configuration file, and which is smarter about "true"/"yes" and "false"/"no" being valid configuration values.
Comment 4 Brian Cameron 2008-04-29 01:11:56 UTC
If you or anybody else wants to also test this patch, that would be great.  I'd love to hear feedback before the next release of the 2.20 branch.