Review Request 112590: Fix todo marker words and detailed completion settings not persistent across application restart.

[Vlas Puhov]

> On Sept. 9, 2013, 1:04 a.m., Andreas Pakulat wrote:
> > shell/completionsettings.h, line 49
> > <http://git.reviewboard.kde.org/r/112590/diff/2/?file=188213#file188213line49>
> >
> >     You should not cast integers read from the config file like this. What happens if the config file contains an int that does not fall into the range used for the enum? IMO having the individual flags as separate boolean entries in the config is also more readable inside the config file. So that should be kept, which means there needs to be code added to actually change those boolean members in the ccpreferences class when another entry is selected.

  I don't understand how can config file contain an int that does not fall into the range? It could only happen if you edit config file manually. But then you should know exactly what you're doing, otherwise you can break anything. And if something goes wrong YOU are the one who responsible for it. And the same goes for any setting, not just completionLevel. Anyway I don't think it's a good idea to change settings manually.
  Moreover seems like this technique (int read from config casted to enum) used throughout kdevelop's code base, see e.g. ExternalScriptPlugin. But if you REALLY edit config files manually all the time and put it's readability above all, ok then I can do it. But again I find it very odd to have three separate entries for one setting (because it's not obvious that those values actually change the same setting).


> On Sept. 9, 2013, 1:04 a.m., Andreas Pakulat wrote:
> > shell/settings/ccpreferences.cpp, line 89
> > <http://git.reviewboard.kde.org/r/112590/diff/2/?file=188217#file188217line89>
> >
> >     I don't think thats the reason, its rather that the CompletionSettings class exposes all these settings to plugins and hence needs to be updated manually in case the config changes.

Yeah, my bad (seems like it works in write-back mode). BTW there is no need in doing those variables public as accessor functions do what we want. Moreover changing them has no affect at all (because accessor functions read values directly from the config, and if value changed in the GUI it immediatly written). So I made those members private.


- Vlas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112590/#review39603
-----------------------------------------------------------


On Sept. 9, 2013, 3:07 p.m., Vlas Puhov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112590/
> -----------------------------------------------------------
> 
> (Updated Sept. 9, 2013, 3:07 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Description
> -------
> 
> CCPreferences class is written with use of KCModule, so all setting can be saved/loaded automatically. For that widget's names should start with kcfg_ prefix, but neither todoMarkerWords nor completionDetail had one, so this feature didn't work.
> 
> 
> This addresses bug 324510.
>     http://bugs.kde.org/show_bug.cgi?id=324510
> 
> 
> Diffs
> -----
> 
>   shell/settings/ccsettings.ui 64d24e2 
>   shell/settings/ccpreferences.h 4ecf623 
>   shell/settings/ccpreferences.cpp 0347fc6 
>   shell/settings/ccconfig.kcfg 1bc89b1 
>   shell/completionsettings.h b3f28ce 
>   shell/completionsettings.cpp 6b6adf6 
> 
> Diff: http://git.reviewboard.kde.org/r/112590/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Vlas Puhov
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20130909/d2d47c06/attachment-0001.html>