D28221: Don't write default value to configuration file when default value came from /etc/* file

[Benjamin Port]

bport added a comment.


  In D28221#641971 <https://phabricator.kde.org/D28221#641971>, @dfaure wrote:
  
  > I have a hard time accepting that the documentation was wrong -- and if it was, then this commit has to fix it, and port as much of the app code that does exactly this, as possible.
  
  
  From my POV documentation is not "wrong", but this point of view describe only default from cpp, no default from global file.
  The current implementation and I don't know why (perhaps I will need to do some archeology there) don't allow to follow default value if it came from a file and follow changes made in the file over time. Like we do with cpp default.
  
  > I don't really know what mReference is. What about a test that uses KConfig directly (no skeletons), to test e.g. what kwindowconfig.cpp?
  >  Sorry to be a non-believer, I just sense a very strong risk of regression here, and if not, then a lot of porting effort. Unless there's a good reason for this stuff to be that way, that we still have to find out.
  
  It's important to consider this kind of stuff. I think we can check to port stuff. However I don't think we can have regression but more incoherence between not yet ported code that will behave like now (don't follow new value in the file providing default) and ported code that will track default if default change in the file.
  
  > I lack time and concentration right now to dig further, but I wanted to not delay my reply longer.
  
  No proble, thanks for all your feedback

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D28221

To: bport, ervin, dfaure, davidedmundson
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200407/d7c06103/attachment.html>