Buffer delay text cut off

[djfun]

Describe the bug
When choosing a buffer delay that is different from the predefined 64, 128 or 256, the text is cut off.

To Reproduce
On linux: start Jack with buffer size 1024
jackd -d dummy -p 1024
Start jamulus and open the settings window
Observe the cut off closing parenthesis.

Expected behavior
Text should not get cut off

Screenshots

Operating system
Ubuntu 20.10

Version of Jamulus
both 3.7.0 and latest master

Additional context
Seems to happen independent from the selected UI language.

[dcorson-ticino-com]

I agree that it would be nice if it didn't cut off, but why would you want to work with such a big buffer?
The latency will make it pretty useless.

[djfun]

The problem is not the longer number, it also gets cut off with just 3 digits:

There are some sound cards which might require a non-standard buffer size. And: if you are just a listener, you might want to work with a larger buffer size for stability reasons.

[djfun]

if I simply add 2 spaces after the text, it works for some reason. But I'm not sure if that is a good workaround:

diff --git a/src/clientsettingsdlg.cpp b/src/clientsettingsdlg.cpp
index 87638faa..0ac032d0 100755
--- a/src/clientsettingsdlg.cpp
+++ b/src/clientsettingsdlg.cpp
@@ -550,7 +550,7 @@ void CClientSettingsDlg::UpdateSoundCardFrame()
     {
         // special title text with buffer size information added
         grbSoundCrdBufDelay->setTitle ( tr ( "Buffer Delay: " ) +
-            GenSndCrdBufferDelayString ( iCurActualBufSize ) );
+            GenSndCrdBufferDelayString ( iCurActualBufSize ) + "  " );
     }
 }

[ann0see]

@djfun Couldd you please open a Pull Request if this issue wasn't resolved?

[djfun]

Problem seems to still exist on current master, I opened a pull request.

[pljones]

I don't like the idea of the fix. It sounds like the styling in the form is wrong: the field should accurately resize to the content.

[hoffie]

It sounds like the styling in the form is wrong: the field should accurately resize to the content.

I had another quick look but don't see anything wrong in our Qt widget/styling usage around grbSoundCrdBufDelay and its title (which is where this information is placed).
I've found the following Qt bug which sounds relevant, but is still unresolved. I'd say it is unlikely to be solved in Qt5 (and therefore: on Ubuntu 20.10) at all: https://bugreports.qt.io/browse/QTBUG-31307

@djfun Can you confirm if you're still running Ubuntu 20.10 as noted in the initial report? 20.10 is no longer supported (by Ubuntu upstream), so if this is not any known issue on a supported platform I'd say we should not introduce workarounds which -- to me -- "only" sounds like a small UI glitch.

[djfun]

I am now using Ubuntu 21.10 (the newest version). Like I wrote in the pull request: maybe the problem only exists with the default font (Ubuntu Regular)..

[ann0see]

maybe the problem only exists with the default font (Ubuntu Regular)..

You can change that probably?

[djfun]

maybe the problem only exists with the default font (Ubuntu Regular)..

You can change that probably?

I can change the font for testing, yes. But I don't want to check 100+ fonts to see if there is another one with the same issue.

[ann0see]

Certainly not. It’s just to ensure that you’re right on the thought that it’s the font misbehaving.