Created attachment 143195 [details] screenshot STEPS TO REPRODUCE 1. open K3b 2. create a data project 3. click on the button above K3b version, in the lower right corner 4. choose CD size > 700 MiB 5. add more than 700 MiB to your project OBSERVED RESULT bar on bottom displays unreadable text. Please see the attached screenshots. EXPECTED RESULT text should always be readable SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Graphics Platform: Wayland
Created attachment 143196 [details] 2nd screenshot - zoom of the bug
Created attachment 143197 [details] 3rd screenshot - readable text when added data does not exceed disc capacity
I was having a look at this, but I'm super confused by the painting in that area. Do you understand what the small blue vertical line is supposed to mean? It's not the used capacity and it's not the free capacity either. My suggestion would be to just drop that vertical line and make the text not move at all, just be centered in regards to the width and that's it, but i want to be sure we're not losing some information first ^_^
Thank you very much for your interest on this issue, Albert. :) Seeing better my first screenshot, there is another unreadable text indicating the amount of added data ('922,5 MiB') in the same horizontal position of 'Rename audio files' button. I also don't understand the purpose of the vertical line, but I like your suggestion. I can test an eventual patch. :)
Created attachment 143331 [details] K3b on Gnome For comparison, I'm posting a screenshot of K3b after the same steps on Arch + Gnome 40.4.0. Another thing, the disc capacity bar was changed a bit in the past due to another bug report, see bug 377105. Yes, I forgot my previous report while opening this one. :(
Created attachment 143341 [details] screenshot of K3b 2.0.2 Qt4 after the provided steps Also for comparison I'm posting screenshots of old K3b 2.0.2 Qt4.
Created attachment 143342 [details] K3b 2.0.2 Qt4 - empty project
This looks like a breeze bug again, k3b is asking for a thick progressbar to be rendered and breeze is ignoring it and rendering a super narrow one and then all the painting breaks, that's why your k3b on gnome screenshot works, it's using a style that respects what the app asks to be renderer, same if you do k3b --style=fusion