334624 2014-05-11 22:09:28 +0000 KCModule::save() unable to access combobox values on OK 2014-06-13 07:41:44 +0000 1 1 3 Frameworks and Libraries frameworks-kconfigwidgets general 4.99.0 unspecified Linux RESOLVED FIXED NOR normal --- 0 sebas kdelibs-bugs-null agateau cfeck kdelibs-bugs-null http://commits.kde.org/kcmutils/cc99fac3af737619ea220ccb7059f0d8f0623efa 0 oldest_to_newest 1447675 0 sebas 2014-05-11 22:09:28 +0000 I have a KCModule that uses a .ui file. When OK'ing the dialog, the ::save() function gets called, but values of a combobox in my .ui are gone by that time. When the module isn't deleted afterwards (Apply), everything works. This is an issue showing with kcmshell5, but not with systemsettings, since systemsettings doesn't show an OK button. Reproducible: Always Steps to Reproduce: 1. Open "Formats" KCM 2. Change value of a combobox 3. Hit OK Actual Results: When reopening the Formats KCM, values have not been applied. Expected Results: Combobox values should have been saved correctly. I've debugged this in the KCM as far as counting values of the combox, and in the problematic case, it's always zero. There seems to be a race condition that the comboboxes are emptied before we can save the config on deletion. My .ui file resulting widget is only deleted in the KCM dtor. Code in plasma-desktop/kcms/formats/kcmformats.cpp show the problematic behavior. (Currently in branch sebas/locale, soon to be merged into master.) 1447687 1 cfeck 2014-05-12 00:02:15 +0000 Hm, I am probably not understanding correctly, but do you think this bug is in kcombobox (which is in kcompletion) or in kcmodule (which is in kconfigwidgets)? 1447701 2 sebas 2014-05-12 01:01:49 +0000 I think it's a bug in KCModule, I'm using QComboBox. That's basically the following going wrong: void KCMFormats::save() { // m_ui->comboBox ends up empty here when OK button is clicked from kcmshell5, // apparently the data in the combo is gone by the time save() is called. // This might be a problem in KCModule, but does not directly affect us // since within systemsettings, it works fine. // See https://bugs.kde.org/show_bug.cgi?id=334624 if (m_ui->comboBox->count() == 0) { qWarning() << "Couldn't read data from UI, writing configuration failed."; return; } //[...] } 1447704 3 cfeck 2014-05-12 01:21:04 +0000 Thanks for the update, reassigning for further investigation. 1454410 4 agateau 2014-06-10 20:46:41 +0000 I have a fix for an issue with one of KWin KCM which looks very similar: https://git.reviewboard.kde.org/r/118639/ 1454771 5 sebas 2014-06-12 15:55:40 +0000 This patch fixes the problem, indeed. 1454896 6 agateau 2014-06-13 07:41:44 +0000 Git commit cc99fac3af737619ea220ccb7059f0d8f0623efa by Aurélien Gâteau. Committed on 10/06/2014 at 14:40. Pushed by gateau into branch 'master'. KCMultiDialog: Fix crash when clicking OK When one closes KCMultiDialog with OK, QDialog::finished() can be emitted before the clicked() signal of the OK button. This causes the following sequence to happen: - KCMultiDialogPrivate::_k_dialogClosed * deletes the KCModule - KCModuleProxyPrivate::_k_moduleDestroyed * sets kcm to 0 - KCMultiDialog::slotOkClicked - KCMultiDialogPrivate::apply - KCModuleProxy::save - KCModuleProxyPrivate::realModule * notices kcm is 0, so recreates it * calls kcm->save() - KWinDesktopConfig::save() * crashes because it expects kcm->load() to have been called To avoid this, trigger the cleanup code in closeEvent() rather than when finished() is emitted, as we can be sure closeEvent() is always called *after* the methods connected to the button box signals has executed. REVIEW: 118639 M +15 -15 src/kcmultidialog.cpp M +2 -1 src/kcmultidialog.h http://commits.kde.org/kcmutils/cc99fac3af737619ea220ccb7059f0d8f0623efa