You are not logged in.
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
Last edited by injiniero (2024-06-12 07:03:49)
Offline
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
Offline
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.
Offline
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?
Offline
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.
Offline
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)
Offline
This issue has been solved in 46.1 version of gnome-calculator
https://gitlab.gnome.org/GNOME/gnome-ca … te_2138545
Last edited by injiniero (2024-06-12 07:05:23)
Offline