GTK theme breaks if user's locale uses commas instead of dots as decimal separators

[LunarEclipse363]

The problem manifests itself as all text using the bold font variant disappearing.

Notably, this means that the text for the active window specifically will disappear from the tasklist.

This happens on the latest git version of awesome (as of writing v4.3-1654-g8b1f8958b).

The problematic line is

theme.gtk.bold_font = theme.gtk.font_family .. ' Bold ' .. theme.gtk.font_size

A solution is to add os.setlocale("C") at the start of the theme file.

[actionless]

that's quite weird you having it only with bold font, as normal font name is computed in the same way:

theme.font          = theme.gtk.font_family .. ' ' .. theme.gtk.font_size

and font_size is stored as number, so there is no extra work done by awesome, but just a pure lua thing:

$ luajit
> a="foo"
> b=5.5
> print(a..b)
foo5.5

if i googled correctly - it seems that lua doesn't support any other decimal separator than a dot (.)

[actionless]

A solution is to add os.setlocale("C") at the start of the theme file.

i think this could cause other side-effects, did you tried smth easier, like:

> print((a..b):gsub("%.", ","))
foo5,5

[LunarEclipse363]

Apparently I didn't run into this with the normal font now because this was the contents of my modified theme

--theme.font          = theme.gtk.font_family .. ' ' .. theme.gtk.font_size
theme.font          = theme.gtk.font_family .. ' ' .. "10"

[AMNatty]

A solution is to add os.setlocale("C") at the start of the theme file.

i think this could cause other side-effects, did you tried smth easier, like:

> print((a..b):gsub("%.", ","))
foo5,5

This incorrect behavior may actually be a regression caused by #3492 to begin with.

[actionless]

could you elaborate, please, why you think so?

[LunarEclipse363]

the first working thing I came up with that uses gsub is this

theme.gtk.bold_font = theme.gtk.font_family .. (' Bold ' .. theme.gtk.font_size):gsub(",", ".")

[AMNatty]

could you elaborate, please, why you think so?

A basic reproducible case could be something like this:

LANG="cs_CZ.UTF-8" lua
Lua 5.4.6  Copyright (C) 1994-2023 Lua.org, PUC-Rio
> "" .. 1.1
1.1
> os.setlocale("", os.LC_ALL)
cs_CZ.UTF-8
> "" .. 1.1
1,1

It's likely there are more cases of stringifying floats in the codebase, something the PR was not aware of

[actionless]

then it looks all correct

mb it's a problem with awesome's textbox() then, which expect a dot despite the locale

could you please try with your locale, if textbox allowing locale-aware font definitions?

[actionless]

however i just checked related code in awesomewm - and apparently that part is whole done using Pango's methods:

https://github.com/awesomeWM/awesome/blob/master/lib/beautiful/init.lua#L156-L191

you can check it here for further investigation

[actionless]

i made a minimal example, so you could test it:

$ luajit
LuaJIT 2.1.1713773202 -- Copyright (C) 2005-2023 Mike Pall. https://luajit.org/
JIT: ON SSE3 SSE4.1 fold cse dce fwd dse narrow loop abc sink fuse
> lgi=require("lgi")
> Pango = lgi.Pango
> desc = Pango.FontDescription.from_string("monospace bold 8.5")
> print( desc:get_size() / Pango.SCALE )
8.5

[AMNatty]

It does indeed print 8.5 until a os.setlocale("", os.LC_ALL), then it prints 8,5

Honestly, I'm going to stop here and disagree with the solution, as locale-aware software-to-software communication is extremely messy at best. I think the best course of action would be to introduce a helper function to format floats (and other sensitive types) without locale-awareness to avoid adding complexity to the codebase. Pango only accepts a C locale-style float anyway (https://docs.gtk.org/glib/func.ascii_strtod.html), so giving it a value of 8,5 results to a completely wrong value of 5. So, with a whole number of 11.0, it results in being interpreted as size 0 (!)