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

[Andreas Pakulat]

> On Sept. 8, 2013, 9:04 p.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.
> 
> Vlas Puhov wrote:
>       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).

It can also happen when switching back and forth across versions for example when sharing some config files across different systems. Anyway, you do have a point in that these are probably rare cases. So how about compromising between 'readable' (reading config files does happen more often than changing manually IMO) and avoiding 3 extra fields: Store a text value instead of the integer. I'm not sure how KConfigSkeleton handles comboboxes, it may be possible to set Qt::DataRole for the entries and get that stored, which would be good as its an untranslated string that can be stored and retrieved without running into localization issues. So you could try wether adding a value for that and changing the field type from int to QString works already, maybe the docs have something on that or otherwise the KDE devel channels (irc, mailinglist) should be able to help.

I guess a configuration-update script is not needed here since these settings haven't been stored properly so far. So there's no need to upgrade existing configs to the new format.


- Andreas


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


On Sept. 9, 2013, 11:07 a.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, 11:07 a.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/a660edaf/attachment-0001.html>