Fixed QSS Styling for YQDialogs

[shundhammer]

Trello

https://trello.com/c/KKQeOWSb Wrong Qt Window Transparency Making Windows Unusable

Split off from
https://trello.com/c/ST2Xm5iz HiDPI - Wrong resolution at Installation

Bugzilla

https://bugzilla.suse.com/show_bug.cgi?id=1199020
https://bugzilla.suse.com/show_bug.cgi?id=1191112

Problem

In some weird situations, YaST Qt UI main windows don't properly clear the background before rendering their own content and just overwrite what was there previously; resulting in something very similar to a transparency effect which makes the whole window unreadable and unusable.

Scenario

In this specific bug, wrongly detected HiDPI caused fonts that were much too large; so the Wizard.rb module fell back to an emergency mode to save screen space, not using the YQWizard (with the side bar), but a simple layout with a plain YDialog instead.

Apparent Cause

There was a problem with QSS styling: Any attempt to set a style for the YQDialog widget class resulted in this wrong rendering.

Selecting the non-installation style.qss with the Shift F3 key combination fixed the wrong transparency effect. Switching back to installation.qss and doing a slash-and-burn approach deleting line by line of installation.qss showed that the offending line was this:

https://github.com/openSUSE/branding/blob/leap-15.4/yast/installation.qss#L6

YQDialog { background: #EEEEEE; color:#333;  }

Deeper Level Cause

Main windows in the Qt UI are managed in a YQMainWinDock class that implements something very similar to a QStackedWidget. But instead of actually using a QStackedWidget, it uses a self-made solution, and that solution had problems: Instead of showing and hiding its YQDialog children to make sure only a single one is visible at any time, it only raised one of them to the top. That's not a problem in most scenarios; but obviously in this specific one it is.

Qt-Level Cause?

For some reason, in the QStyleSheet widget style that is used when QSS style sheets are used, some of those widgets become transparent, and the problem we observed here appears.

This may be a bug in the Qt libraries; or it may be a bug in the way we use them. But whichever it is, we need a solution on our level.

Fix

Ensure that only one of the YQDialogs in the YQMainWindDock is visible at any given time: When raising the toplevel dialog, also make sure to hide() all the others. So whatever buggy transparency may appear, it doesn't matter because there is nothing to shine through the current toplevel dialog.

Test

The problem can be reproduced even in the installed system:

• Make sure to use the TW / Leap installation.qss
• Enforce the Wizard.rb emergency mode
• Start the YaST partitioner
• Select one of the partitions, then hit the "Edit" button

xhost +
sudo Y2STYLE=installation.qss QT_SCREEN_SCALE_FACTORS=2 yast2 partitioner

Without this Fix

With this Fix

[ancorgs]

I'm trusting @Vogtinator review here and approving in consequence.

I just wonder if this deserves some backporting since I have heard about similar problems for quite some time, so I guess 15.4 at least is affected.

[shundhammer]

@Vogtinator mentioned this in the bug:

https://doc.qt.io/qt-5/qwidget.html#autoFillBackground-prop

autoFillBackground : bool

...
Warning: Use this property with caution in conjunction with Qt Style Sheets. When a widget has a style sheet with a valid background or a border-image, this property is automatically disabled.

void setAutoFillBackground(bool enabled)

So it is actually a problem of the Qt libs; they documented it, but that means that we have to find a workaround for every instance where we need that widget property.