Version: (using Devel) Installed from: Compiled sources OS: Linux After making changes to settings in a settings page. If the user moves on without applying the changes the "unsaved changes" dialog box appears asking if you want to save or discard the changes. If the user selects cancel here s/he is put back to the settings page they just left, with their settings still waiting to be applied BUT now the apply button is disabled.
using 4.1 beta 1 from ubuntu repositories
Correction it appears that the changes are actually committed when you cancel the "unsaved changes" dialog. It also appears that the icons denoting the page I'm on is now not indicating the correct page. eg:- 1) select appearance->fonts 2) change fonts 3) select icons page (still under appearance) 4) in "unsaved changes" dialog select cancel 5) changes have still been applied 6) although we are back in the fonts page the page selection on the left still indicates we are on icons page
I can confirm what Robert wrote on comment #2. I're reproduced using current trunk.
I'm following the bug in comment 3, and it seems to be a bug in KDEUi
*** Bug 164122 has been marked as a duplicate of this bug. ***
*** Bug 193509 has been marked as a duplicate of this bug. ***
SVN commit 1070452 by cfeck: Fix wrong selected icon after canceling changes The problem was the signal blocking. CCMAIL: sourtooth@gmail.com BUG: 163693 M +1 -1 ModuleView.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1070452
SVN commit 1070487 by cfeck: Revert last commit This unfortunately crashed when going back to overview. Ben, could you look into this? I really like would bug 163693 fixed. CCBUG: 163693 CCMAIL: sourtooth@gmail.com M +1 -1 ModuleView.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1070487
This is a bug in the KDELibs class I think, which doesn't change the selected item in the side view when performing the change of current page programatically. I have to block signals in the function which checks for changes since otherwise the setCurrentPage() call will result in it being called recursively.
*** Bug 228270 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > This is a bug in the KDELibs class I think... Yes, I reached this bug when make own dialog through KPageDialog. I try to handle "apply/reject/cancell" fallback using KPageDialog::currentPageChanged(KPageWidgetItem *current, KPageWidgetItem *before) signal, and when in connected slot I call currentPageChanged::setCurrentPage(before), then such effect appeared.
Bug fixed in r1168413 by correcting KPageView's connection to selectionChanged() instead of currentChanged() WebSVN. http://websvn.kde.org/?revision=1168413&view=revision
Backported to 4.5 branch for 4.5.1 (to keep fresh and impatient contributors going ;) http://websvn.kde.org/?revision=1168462&view=revision