gnome calculator decimal point not working with es_ES.UTF8 locale

injiniero · 2024-04-27 14:38:29

Gnome-calculator 46.0-1 version doesn't respect my system locale (es_ES.UTF8) for the decimal point key in numpad. It should be interpreted as a "," (comma)

When I press the "." key in numpad, libreoffice calc shows a "," instead and this is the behaviour expected.
Gnome-calculator take the "." press as is (the dot) and this is useless with my locale and forces me to press the comma key.

Any idea to solve this?

Thanks

seth · 2024-04-27 15:54:24

Is this limited to gnome-calculator or do eg. the gnome terminal and text editor behave the same?
(The input is controlled by the keyboard layout, not the locale, and I susupect you might see LO on xwayland and using a different layout there - but gnome could totallly map around the input for the numpad and the calculator specifically)
Is this gnome on wayland or or X11?
For x11, adding

Option      "XkbSymbols" "+kpdl(commaoss)"

to the keyboard layout config (or transiently "setxkbmap -symbols '+kpdl(commaoss)'" will make that thing enter a comma, but idk. whether gnome/wayland will parse that from the xorg config and setxkbmap will be limited to xwayland

injiniero · 2024-04-27 17:52:40

This is on X11.
The dot (.) key in numpad is interpreted as a dot on all the apps that doesn't expect a decimal point as input. So I said that in libreoffice calc it shows a comma when the dot key is pressed in the numpad and this is what the gnome-calculator should interpret as well, but it doesn't.

seth · 2024-04-27 20:52:48

interpreted as a dot on all the apps that doesn't expect a decimal point

Isn't really a helpful description of the status quo and also not exactly how this works

setxkbmap -print -query
xev -event keyboard

Ideally™, the key generates KP_Separator and the client can then interpret that as they see fit - apparently LO calc takes it as comma but the general resolution of your layout is a dot.
An additional layer of complexity might be an IM, gnomestuff™ defaulting to ibus - https://wiki.archlinux.org/title/Input_method
So it might shed some more light if you could name some clients that actually interpret this as comma and some that interpret it as dot (to rule out eg. a LO calc specific setting)

As mentioned, you can force it to enter a comma regardless, but first let's see your actual layout/variant/options and what the key generates.
But then there's also https://gitlab.gnome.org/GNOME/gnome-ca … /issues/86 which suggests the calculator would actually not care at all and accept both entrances?

injiniero · 2024-04-28 15:24:53

After some research this is what I've got.

Libreoffice setting:
Decimal point key in numpad as locale (,) <- comma

Checking my locale configuration

localectl command output:

localectl 
System Locale: LANG=es_ES.UTF8
    VC Keymap: es
   X11 Layout: es

Checking the keystroke

xev -event keyboard
After pressing the dot key in numpad

KeyPress event, serial 28, synthetic NO, window 0x2800001,
    root 0x2cd, subw 0x0, time 3302817, (1007,-56), root:(2687,764),
    state 0x10, keycode 91 (keysym 0xffae, KP_Decimal), same_screen YES,
    XKeysymToKeycode returns keycode: 129
    XLookupString gives 1 bytes: (2e) "."
    XmbLookupString gives 1 bytes: (2e) "."
    XFilterEvent returns: False

It returns KP_Decimal

Searching at the gnome-calculator source code
src/ui/buttons-basic.ui

<object class="GtkButton" id="calc_numeric_point_button">
            <property name="label" comments="Label is set in gtk.c to comply with LC flags">.</property>
            <property name="receives_default">1</property>
            <property name="use_underline">1</property>
            <property name="focus_on_click">0</property>
            <property name="action_name">cal.insert-numeric-point</property>
            <style>
              <class name="numeric-point-button"/>
            </style>
            <layout>
              <property name="column">1</property>
              <property name="row">4</property>
            </layout>
</object>

The dot button press is handled at insert-numeric-point function.
The comment in the label is quite old. Now the label is set at src/math-buttons.vala

/* Configure buttons */
        var button = builder.get_object ("calc_numeric_point_button") as Gtk.Button;
        if (button != null)
            button.set_label (equation.serializer.get_radix ().to_string ());

and get_radix() method returns the radix property defined at lib/serializer.vala

private unichar radix;           /* Locale specific radix string. */
    private unichar tsep;            /* Locale specific thousands separator. */
    private int tsep_count;          /* Number of digits between separator. */

    /* is set when an error (for example precision error while converting) occurs */
    public string? error { get; set; default = null; }

    public Serializer (DisplayFormat format, int number_base, int trailing_digits)
    {
        var radix_string = Posix.nl_langinfo (Posix.NLItem.RADIXCHAR);
        if (radix_string != null && radix_string != "") {
            var radix_utf8 = radix_string.locale_to_utf8 (-1, null, null);
            if (radix_utf8 != null)
                radix = radix_utf8.get_char (0);
            else
                radix = '.';
        }
        else
            radix = '.';

To check the nl_langinfo function I've writen this code found in the man pages

#include <langinfo.h>
#include <locale.h>
#include <stdio.h>
#include <stdlib.h>
int
main(void)
{
    setlocale(LC_CTYPE, "");
    setlocale(LC_NUMERIC, "");
    printf("%s\n", nl_langinfo(CODESET));
    printf("%s\n", nl_langinfo(RADIXCHAR));
    exit(EXIT_SUCCESS);
}

And this is the output in my system

UTF-8
,

RADIXCHAR in my locale is a comma as it should be.

Keystrokes are processed at src/math-display.vala

/* Numeric keypad will insert '.' or ',' depending on layout */
        if ((keyval == Gdk.Key.KP_Decimal) ||
            (keyval == Gdk.Key.KP_Separator) ||
            (keyval == Gdk.Key.period) ||
            (keyval == Gdk.Key.decimalpoint) ||
            (keyval == Gdk.Key.comma))
        {
            equation.insert_numeric_point ();
            return true;
        }

KP_decimal is what xev returns when I press the dot key in numpad, so it should call insert_numeric_point which is defined at lib/math-equation.vala

public void insert_numeric_point ()
    {
        Gtk.TextIter iter_prev;
        get_iter_at_mark (out iter_prev, get_insert ());
        /** go back to the first digit of the currently entered number **/
        while (iter_prev.backward_char () && (iter_prev.get_char () == serializer.get_thousands_separator ()
                || iter_prev.get_char ().isdigit ()
                || iter_prev.get_char () == serializer.get_radix ()))
            ; // do nothing

        if (!iter_prev.is_start ())
            iter_prev.forward_char ();
        var current_number = "";

        /** find the currently entered number, ignoring thousand separators and including decimal point **/
        while (iter_prev.get_char () == serializer.get_thousands_separator ()
                || iter_prev.get_char ().isdigit ()
                || iter_prev.get_char () == serializer.get_radix ()) {
            if (iter_prev.get_char ().isdigit ()) {
                current_number += iter_prev.get_char ().to_string ();
            }
            if (iter_prev.get_char () == serializer.get_radix ()) {
                current_number += ".";
            }
            iter_prev.forward_char ();
        }

        insert (serializer.get_radix ().to_string ());
    }

which insert serializer.radix char that should be a comma but it isn't.

I've tested Fedora 39 with GNome 45.5 and gnome-calculator 45.0.2 and when I press the dot key a comma is inserted (as expected).
I've tested on new Ubuntu 24.04 with gnome 46 and gnome.calculator 46 and the dot key fails as in my Archlinux system with gnome 46.

I haven't seen any differences between current and 45.0.2 in gnome-calculator code (into the above snippets of code).
I can't figure out where the problem is located.

seth · 2024-05-01 15:15:20

ftr (I know you've found that), https://gitlab.gnome.org/GNOME/gnome-ca … issues/403

serializer.vala hasn't been changed since 3+ years
Have you tried https://archive.archlinux.org/packages/ … kg.tar.zst on the current gnome 46 (since gnome treats API stability as hypothetical, it might not even start but it's probably interesting to see whether it behaves the same if it does)

Also check

tr '\0' '\n' < /proc/$(pidof gnome-calculator)/environ

to see whether it maybe sees an unexpected locale

This here looks suspicious:
https://gitlab.gnome.org/GNOME/gnome-ca … 82edaf3fc1
https://gitlab.gnome.org/GNOME/gnome-ca … issues/392

Last edited by seth (2024-05-01 15:18:42)

Arch Linux

#1 2024-04-27 14:38:29

gnome calculator decimal point not working with es_ES.UTF8 locale

#2 2024-04-27 15:54:24

Re: gnome calculator decimal point not working with es_ES.UTF8 locale

#3 2024-04-27 17:52:40

Re: gnome calculator decimal point not working with es_ES.UTF8 locale

#4 2024-04-27 20:52:48

Re: gnome calculator decimal point not working with es_ES.UTF8 locale

#5 2024-04-28 15:24:53

Re: gnome calculator decimal point not working with es_ES.UTF8 locale

#6 2024-05-01 15:15:20

Re: gnome calculator decimal point not working with es_ES.UTF8 locale

Board footer