wwmm
In NL locale, some labels in Automatic Gain are impossible to read in full and tell apart
EasyEffects Version
7.1.6
What package are you using?
Fedora
Distribution
Fedora 40
Describe the bug
There are various... modes of computation for Auto Gain, but in NL locale most of them look exactly the same because the text is truncated and I can't find a way to make it show the full string.
Expected Behavior
Width of the labels not being too small
Debug Log
Debug Log
Paste your log here
Additional Information
Latest version of KDE, Wayland, display scale 200%. This is not a new problem, seen it for a while already.
@Digitalone1 I do not remember well but I think that at some point in the past we tried to fix this kind of problem but faced some kind of limitation in gtk/libadwaita. Do you remember what it was?
In any case even if we find a way to make libadwaita to accept longer strings at some point the strings will have to be truncated. Maybe the proper solution is using a different translation. But as I do not know the language this is out of my reach.
Latest version of KDE, Wayland, display scale 200%.
I also use KDE. Although on my monitor it does not make sense to use 200% as scaling I did it now for testing purposes. The English string is fine both at 100% and at 200%.
In any case even if we find a way to make libadwaita to accept longer strings at some point the strings will have to be truncated.
Actually this is only true before opening the dropdown menu. In its menu there is much more space for longer strings.
Maybe the proper solution is using a different translation.
(looking here) maybe it's OK to use an abbreviation (not sure if it always ok, and here they could imply it's only for the not-inflected form?), e.g.
Geometrisch gem. (MSI)
then it's only 2 characters longer than English
and maybe Meetkundig instead of Geometrisch - 1 char shorter
Meetkundig gem. (MSI)
So maybe this is a solution.
Is there a way to start easyeffects with different language without changing system wide language? I probably should verify if the English text would fit on my system to rule out any additional surprises.
Is there a way to start easyeffects with different language without changing system wide language? I probably should verify if the English text would fit on my system to rule out any additional surprises.
Yes. Something like LANG=en_US.UTF-8 easyeffects should be enough.
Our translations are provided by volunteers on weblate. As you know the language you may try to improve them if you want and have time.
English strings work for me too, I will try to go that route soon, thanks!
@Digitalone1 I do not remember well but I think that at some point in the past we tried to fix this kind of problem but faced some kind of limitation in gtk/libadwaita. Do you remember what it was?
No, we only talked about it in #2508
But I think there's nothing we can do.
Anyway, in order to offer a workaround, I always thought we had to add a language chooser in the app settings, so the user can switch to English easily without using the command line.
@Digitalone1 I do not remember well but I think that at some point in the past we tried to fix this kind of problem but faced some kind of limitation in gtk/libadwaita. Do you remember what it was?
No, we only talked about it in #2508
But I think there's nothing we can do.
Thanks. I completely forgot about that open issue.
Anyway, in order to offer a workaround, I always thought we had to add a language chooser in the app settings, so the user can switch to English easily without using the command line.
The question is if this can be done without relaunching the application. But even it there is a way it does not feel right to have to go to so far to solve a problem that could be solved easily if the toolkit allowed the string size to be customized in that location...
Using the system locale is completely fine, I'm not sure any in-app choice is even necessary.
But what part does libadwaita play here? Is it perhaps using English text as a reference for choosing the width? Could it be possibly hacked by making the corresponding English strings artificially longer, like invisible characters of some sort, or maybe expanding those 2-3 letter abbreviations?
But what part does libadwaita play here? Is it perhaps using English text as a reference for choosing the width? Could it be possibly hacked by making the corresponding English strings artificially longer, like invisible characters of some sort, or maybe expanding those 2-3 letter abbreviations?
I do not think it depends on the English string size because this can happen with English strings too if they are long enough. Most likely libadwaita has a hardcoded maximum width value in that menu. It does this on other places and it isn't necessarily a bad thing. Qt libraries like Kirigami for KDE also have some hardcoded borders or maximum values in some places. But I think that in this menu libadwaita devs exaggerated on how small they want the menu width to be.
I think part of the problem is that nobody here knows exactly how libadwaita/gtk decides the dimensions of the popup, so we're not sure where to even start looking.
Edit: I was just reading through autogain.ui and I noticed the property title-lines on a ComboRow, which it inherits from Adw.ActionRow. I'm not quite sure what it does. Does anyone know exactly?
Is the width in the GtkStringList from the ui definition file maybe decided at compile-time instead of run-time?
and maybe Meetkundig instead of Geometrisch - 1 char shorter
Meetkundig gem. (MSI)
So maybe this is a solution.
Committed these changes to the EasyEffects hosted weblate project.
Is the width in the
GtkStringListfrom the ui definition file maybe decided at compile-time instead of run-time?
No. it isn't. The width of the labels is calculated at runtime.