Gui Broken After Upgrading to Pop!_OS 20.10

Tags: #<Tag:0x00007fbb44750718> #<Tag:0x00007fbb447504c0> #<Tag:0x00007fbb447501c8>

After upgrading my operating system from 20.04 to 20.10, the gui of picard was made dysfunctional. Scaling the window doesn’t change anything.
Using the pop-dark theme under gnome, at qt5configuation tool to theme qt applications. Changing syles in the qt5 configuation doesn’t change anything.

Please see if turning off “Use system theme” makes the UI usable again.

That’s exactly why using the system’s theme is behind an option with a clear warning. We have no control over third party themes, and this Qt theme clearly does not work well. If this worked before this means they broke the theme with this update. Picard’s options menu really is nothing special. If a simple use of labels and checkboxes in a vertical layout does break so badly that Qt theme probably wasn’t tested that well. You shod report it to Pop_OS or whoever is creating this theme.

That is not the issue, because the issue existed before checking that box. I had checked the box in an attempt to fix the issue. In hindsight, unchecking the before screenshotting for the post would have been bright. Checking it changed nothing but the colour.

Ok, I see. To narrow this down, do you have scaling enabled in Gnome’s settings? Does turning scaling off or changing the scale factor make a difference.

Cod you also check whether there are any QT_ environment variables set? You should be able to list them from a terminal with

env | grep QT_

I am not using scaling, however I checked, and setting scaling to any value other than the normal 100% does fix the issue. (Obviously this isn’t a feasible solution) Perhaps it’s relevant that the resolution of both of my displays is 1680x1050, however changing the display resolution doesn’t make any difference.

These are my QT_ env variables

setting QT_SCALE_FACTOR to 1.08 or higher appears to fix the issue. As a workaround for now, I will open picard from a shell and make sure that enviroment variable is set locally in the shell beforehand. Make a little script for ease ofc.

1 Like

I think this is actually the same as reported in

There it seems like the system’s DPI resulted in a scale factor < 1.0. In this issue I had assumed / hoped that setting QT_SCALE_FACTOR=1 would be enough, but it seems at least in your case it needs to be higher.

This is all because we allowed for fractional scaling :frowning: Qt’s UI scaling is really a mess, and it tends to change from version to version. I’m thinking about just removing the fractional scaling for platforms other than Windows (where scaling is not working well otherwise) again. Before we introduced it things at least worked rather well on Linux.

1 Like