Bug 274629

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.