Version: 2.0.89 (using KDE 4.6.3) OS: Linux The apply button does not become disabled if the state of the configuration is changed back to the former values. Reproducible: Always Steps to Reproduce: Open the configuration dialog -> apply button is grayed out Change some button (like enabling custom fonts) -> apply button is enabled Reset to the former value -> apply button is still enabled OS: Linux (i686) release 2.6.37-12-desktop Compiler: gcc
Work fine here. I close it now
The bug is still there (or again), in KDE 4.9.3, so please reopen! At the same time, just the other way around, the "Reset" button should be active only if any value has currently been changed and was not reverted or applied. This obviously isn't major bug, but neither it is nitpicking, as it gives especially the unexperienced user feedback about the current state of the dialog and about the risk of changing something unintendedly.
reopening, per Bernd's testing
"The bug is still there (or again), in KDE 4.9.3, so please reopen!" need to know which settings do you change and when you click For me in font it works fine.
(In reply to comment #4) > "The bug is still there (or again), in KDE 4.9.3, so please reopen!" need to > know which settings do you change and when you click > For me in font it works fine. Ah, now I know why there is confusion: we were finally talking about two different things. I (and probably also the original reporter) was talking about /manually/ undoing changes: 1. Change something => "Apply" button appears 2. Change it back => "Apply" and "Reset" buttons don't disappear but should Marking this one depend on some first step, handling the "Reset" button, see Bug #274629. Fixing the other one first, seems to make sense, before figuring out this tricky one here. It's not an absolute requirement though.
> Change it back => "Apply" and "Reset" buttons don't disappear As far as I know, no other KDE dialog does it. If you change a value, then change it back, these are recorded as two changes.
(In reply to comment #6) > As far as I know, no other KDE dialog does it. If you change a value, then > change it back, these are recorded as two changes. Thanks, Christoph, for your feedback! Considering that this could become very tricky with more complex widgets, this IMHO means that the issue simply can't be solved within kdepim's scope. So we can: - move this issue as a wishlist to the kdelibs queue - mark it as a duplicate of some kdelibs issue, if existing - simply mark it WONTFIX. I'm not sure which would be the way to go.
We got bug 183948 for System Settings, but as is indicated there, we do not have a general solution. In fact, with the current KConfigXT framework, it might be impossible for a dialog to undo the changed state, except by using the Save/Apply/Revert buttons.
I confirm it, it's still the case for Plasma 5.17.5
Which KCM can you confirm this for?
(In reply to Nate Graham from comment #10) > Which KCM can you confirm this for? If no submodules are given, all are effected: 1) Global Designs 2) Application Styles 3) Colors 4) Symbols 5) Workspace -> Edges 6) Workspace -> Touchscreen 7) Workspace -> Activities 8) Windows -> Behaviour 9) Windows -> Application Switcher 10) Windows -> KWin Scripts 11) Windows -> Window Rules 12) Shortcuts -> Standard shortcuts 13) Shortcuts -> Webshort cuts 14) Shortcuts -> Own Shortcuts 15) Start and Shutdown -> SDDM 16) Start and Shutdown -> Background Tasks 17) Start and Shutdown -> Workspace Session 18) Search 19) Personal Information -> Notifications 20) Accounts -> KDE-Passwordmanager 21) Regional Settings -> Formats 22) Regional Settings -> Corrections 23) Regional Settings -> Clock 24) Applications -> Standard 25) Applications -> File links 26) Applications -> Files 27) Aid 28) Network -> Settings 29) Network -> Connections 30) Hardware -> Input -> Keyboard 31) Display and Monitor -> Compositor 32) Display and Monitor -> Gamma 33) Energy 34) Pluggable Media -> Pluggable Media
Ah yes. Thankfully this is getting fixed KCM-by-KCM and most of the Appearance ones were already done in 5.18. More are being done in 5.19. No need for a bug report tracking it since it's currently in progress.