After upgrading qgnomeplatform-qt5 from 0.8.4-12 to 0.9.0-1 on Fedora 36, the platform/theme settings are not applied in VirtualBox VM processes anymore.
I.e., after launching the VirtualBox, the main application window is correctly themed (uses dark theme as expected), but launching
a VM, its window is not (appears to be using fusion theme, and opening Devices -> Optical Drives -> Choose a disk file opens a fusion-style file selection dialog).
Bisection between 0.8.4 and 0.9.0 seems to point to this commit: 28f14d370e5e7a6b9f68e90837ea58a60d9ef65b
Instrumenting the portal hint provider code in HEAD with extra debug message that dumps resultMessage.type() and resultMessage.arguments()here shows that type is 3 (QDBusMessage::ErrorMessage) and arguments are
(QVariant(QString, "Portal operation not allowed: Unable to open /proc/95226/root"))
So it seems that we are now trying to use the portal but cannot really do so - presumably due to VirtualBox's own sandboxing. And the portal provider codepath lacks a fall back for such cases.
After upgrading
qgnomeplatform-qt5from0.8.4-12to0.9.0-1on Fedora 36, the platform/theme settings are not applied in VirtualBox VM processes anymore.I.e., after launching the VirtualBox, the main application window is correctly themed (uses dark theme as expected), but launching a VM, its window is not (appears to be using fusion theme, and opening
Devices -> Optical Drives -> Choose a disk fileopens a fusion-style file selection dialog).Bisection between
0.8.4and0.9.0seems to point to this commit: 28f14d370e5e7a6b9f68e90837ea58a60d9ef65bInstrumenting the portal hint provider code in HEAD with extra debug message that dumps
resultMessage.type()andresultMessage.arguments()here shows thattypeis3 (QDBusMessage::ErrorMessage)andargumentsareSo it seems that we are now trying to use the portal but cannot really do so - presumably due to VirtualBox's own sandboxing. And the portal provider codepath lacks a fall back for such cases.