go trough all kdeds to see the use cases of the use of widgets by kded
Description
Status | Assigned | Task | ||
---|---|---|---|---|
Open | None | T12187 Meta task: KDED | ||
Resolved | davidedmundson | T12191 KDED: qwidget dependency |
Internally in kded it is used to
- in Kded::platformSupportsModule, get the platformName used to check to desktop property X-KDE-OnlyShowOnQtPlatforms
- to access QApplication (i.e QGuiApplication) to set setDisplayName in setupAppInfo(QApplication *app)
- to qApp.setQuitOnLastWindowClosed(false) in kdemain
All those should be good candidate for removal, plafformName can be replaced by reading XDG_SESSION_TYPE, this is already done in detectPlatform().
Code in QGuiApplication for reference: https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp?h=dev#n1386
I'd
Once this was done, it build all kdedModule I found in my local checked out repos :
kio plasma-desktop plasma-workspace powerdevil kinit print-manager plasma-nm kio-extras kscreen kdbusaddons plasma-vault plasma-browser-integration kmix kaccounts-integration kdelibs4support baloo bluedevil
So at list all those KDED don't depend on kded internal QApplication to be a QGuiApplication.
I might be missing some though.
I found the project wacomtablet uses the Kded QGuiApplication internally to detect screens and related events.
It could be replaced by dbus calls instead.
Hence D25500 breaks wacomtablet.
Getting rid of widgets and QApplication doesn't necessarily mean getting rid of QtGui and QGuiApplication. They are a lot lot lighter.
All right good to know.
So if I understand correctly the goal here would be to make Kded application a QGuiApplication, in which case from what I check we can go ahead (wacomtablet would be fine).
I don't think this is something we can do. Some modules want to show a dialog, e.g. plasma-nm for the wifi password. I also don't think we would gain much from it