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

[David Faure]

> On Jan. 18, 2012, 3:39 p.m., Jeremy Paul Whiting wrote:
> > 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.

We are definitely not keeping BC in frameworks. What, with splitting code into different libs, moving code around, etc. So no issue here.


- David


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


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/3ae15d3d/attachment.htm>