I wanted to get rid of the duplicate scaling we do, but I noticed that the settings dialog still receives scaling events even though it opted out of custom scaling. This is because of our widget-tree, where the settings window is a descendant of the main window, causing setScale to be called on it (~> and its children). That's not desired.
So instead of using Qt's findChildren, we're now using a custom recursive loop over all children. Its general structure is similar to Qt's, except that we don't keep a list. This might bite us if any objects are added/removed while iterating (in that case we can dump them into a vector first). If any BaseWindow is encountered that has custom scaling disabled, we won't go into it (that's the main fix).
I also found a misleading call to scale in the settings dialog I missed in #4868 (the scale is always 1).
I wanted to get rid of the duplicate scaling we do, but I noticed that the settings dialog still receives scaling events even though it opted out of custom scaling. This is because of our widget-tree, where the settings window is a descendant of the main window, causing
setScaleto be called on it (~> and its children). That's not desired.So instead of using Qt's
findChildren, we're now using a custom recursive loop over all children. Its general structure is similar to Qt's, except that we don't keep a list. This might bite us if any objects are added/removed while iterating (in that case we can dump them into a vector first). If anyBaseWindowis encountered that has custom scaling disabled, we won't go into it (that's the main fix).I also found a misleading call to
scalein the settings dialog I missed in #4868 (the scale is always 1).