Review Request: Use KCoreConfigSkeleton argument type where possible inside the KConfigDialog

[Jeremy Paul Whiting]

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


Looks good to me as long as we aren't trying to keep BIC in frameworks.  If we are, a duplicate method with KConfigSkeleton that simply calls this new method should be added to keep BC.

- Jeremy Paul Whiting


On Jan. 17, 2012, 9:28 p.m., Laszlo Papp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103719/
> -----------------------------------------------------------
> 
> (Updated Jan. 17, 2012, 9:28 p.m.)
> 
> 
> Review request for kdelibs and Jeremy Paul Whiting.
> 
> 
> Description
> -------
> 
> Use case: there are applications, like kanagram, which would be nice to have
> running on several platforms, as in handsets; for instance Harmattan on N9. It
> would be nice to use the same settings code generation in certain cases for all
> the platforms. The additions of KConfigSkeleton on the top of
> KCoreConfigSkeleton are the font and color settings which are currently not
> used in couple of KDE applications. Hence, it should not be mandatory. The
> kdeui module is unlikely welcome on mobile platforms, especially in appstores
> with its sizes and complexity for no real need.
> 
> KConfigDialogManager has apparently already two constructors (ie.: the need
> already arised previously for such an approach); one with KConfigSkeleton
> argument type, and yet another with KCoreConfigSkeleton. It looks like a
> situation where the KCoreConfigSkeleton version was added for good.
> 
> The KConfigDialog constructor does not handle KCoreConfigSkeleton argument
> type yet; it has probably somehow been missed so far. Changing the current
> constructor to KCoreConfigSkeleton usage is a good way because it does not
> cause any API break; a simple recompilation is enough in client applications.
> 
> 
> Diffs
> -----
> 
>   kdeui/dialogs/kconfigdialog.h 2ac0eda 
>   kdeui/dialogs/kconfigdialog.cpp e815e54 
> 
> Diff: http://git.reviewboard.kde.org/r/103719/diff/diff
> 
> 
> Testing
> -------
> 
> Build test on Linux
> 
> 
> Thanks,
> 
> Laszlo Papp
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120118/c5c9bc12/attachment.htm>