Change Details

(after a log of looking, it turns it's out not a bug in the QQC desktop style) KSharedConfig::openConfig() opens the config based on the app name. The app name comes from the exec name, or KAboutData::setApplicationData. setApplicationData only works on an existing qApp. This means the QPT loaded in the QApp uses the wrong config. The effect is minimal because most stuff is in kdeglobals, but it means the KSharedConfigPtr is not shared with the one used elsewhere in the app. This is wasteful, but also means the QPT calling reparseConfiguration doesn't take effect, leading to colours not being dynamically updated

(after a lot of looking, it turns it's out not a bug in the QQC desktop style) KSharedConfig::openConfig() opens the config based on the app name. The app name comes from the exec name, or KAboutData::setApplicationData. setApplicationData only works on an existing qApp. This means the QPT loaded in the QApp uses the wrong config. The effect is minimal because most stuff is in kdeglobals, but it means the KSharedConfigPtr is not shared with the one used elsewhere in the app. This is wasteful, but also means the QPT calling reparseConfiguration doesn't take effect, leading to colours not being dynamically updated

(after a logt of looking, it turns it's out not a bug in the QQC desktop style) KSharedConfig::openConfig() opens the config based on the app name. The app name comes from the exec name, or KAboutData::setApplicationData. setApplicationData only works on an existing qApp. This means the QPT loaded in the QApp uses the wrong config. The effect is minimal because most stuff is in kdeglobals, but it means the KSharedConfigPtr is not shared with the one used elsewhere in the app. This is wasteful, but also means the QPT calling reparseConfiguration doesn't take effect, leading to colours not being dynamically updated