Version: (using KDE 4.1.0) Installed from: Debian testing/unstable Packages no warning when closing modified scoring dialog Steps --> fresh knode, edit scoring, I set the parameters for the rule, clicked OK (this causes closing the window). Again -> edit scoring. No rules. All my work was simply lost. Please, check on closing the dialog if the data are/not modified.
Created attachment 28481 [details] fix the classname of object used to match conditions & actions
Created attachment 28482 [details] Fix the display of previously stored actions Additional patch to the first one
Looks good, but I suggest to use something more safe than the classname comparison, like eg. dynamic_cast or qobject_cast to avoid similar problems in the future. Anyway, please commmit.
SVN commit 883902 by otrichet: Fix edition of scoring rules (saving and loading the UI) CCBUG: 170030 CCBUG: 175045 M +10 -6 kscoringeditor.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=883902
Let's move here: "The standard meaning of the [X] button is "cancel", so there is no needed confirmation." Remark: there is "no standard meaning" of [x]. [x] _is_ close. Refer to KDE window decoration description. But this is irrelevant here. The report said explicitly that there is no warning when closing modified rules. It is closed as fixed and now you are saying there is no confirmation. So either there is some misunderstanding or the issues is not fixed at all, because whole point was to add confirmation dialog when closing modified rules.
Maciej, you opened 2 bugs in row #170030 and #170031. The bug #170031 was about conditions and actions of rule not being saved, this is definitly corrected. This bug (#170030) says: "Steps --> fresh knode, edit scoring, I set the parameters for the rule, clicked OK (this causes closing the window). Again -> edit scoring. No rules. All my work was simply lost." This is the same issue as in #170031, rules *were* not save in knode (from kde4). You also write in this report to "check on closing the dialog if the data are/not modified.", but please reread your initial report and you'll see it was not obvious at all that you were speaking about click on [x]. Therefore, I consider this bug as *fixed* for the first part, and *wontfix* for the second one.
My apologies, I meant [x] not OK. Sorry for that unfortunate mistype. So, what will happen now: 1) user enter scoring 2) user spends 1 hour polishing scoring rules 3) user by accident clicks on [x] 4) and...?