Meh - in case of the BCM2045 - this chipset should work - whatever it need, i would suggest google for the rescue
the reason to use qt5ct was i had wanted to only use kvantum. with qtstyleoverride but i noticed no icon theme/cursor/font was set. and did not use lxqt because it pulls other things which is not needed. and to use lxqt-qtplugin we need lxqt-config also so more than half lxqt installed in terms of deps. and the redundant app here is lxqt-config. as except bightness and appearance. nothing works on wayland. from it.
This isn’t the first time I see bad bugs in qt5ct. It’s a shame that your nice ISO is affected by serious bugs of a small program.
I don’t need to say anything about nice features that LXQt and KDE Qt plugins have but qt5ct lacks…
The fine thing in debian is: KDE blocks q5ct on a very low level - and it also works fine for LXQt - i was really proud of the guys
Today, I found the root of Qt5ct’s bug in handling tool buttons and included a workaround in Kvantum (and released Kvatum 0.13.0). But a glance at Fusion with Qt5ct shows how terribly Qt5ct handles toolbar buttons…
How? You mean, under KDE, if you enter
export QT_QPA_PLATFORMTHEME="qt5ct" in QTerminal and then run a Qt app in it, the app won’t be handled by qt5ct? If so, that’s a wise decision, IMO, because KDE’s Qt plugin is very good. Ours is excellent
Actualy, if that’s possible, I think we should block
qt5ct too. I vaguely remember an invalid bug report, whose cause was that the user had used
qt5ct under LXQt.
the KDE/Qt guys in debian asked me years ago if i would be fine with:
agaida@ramme /etc % cat X11/Xsession.d/99qt5ct :( # Enable qt5ct by default unless another PLATFORMTHEME option is set # or KDE is running. if [ -z "$QT_QPA_PLATFORMTHEME" ] && [ "$XDG_CURRENT_DESKTOP" != "KDE" ] then export QT_QPA_PLATFORMTHEME=qt5ct fi
i was - we set our platformtheme before