Review Request: Replicate the existing KConfigDialog constructor and change one argument type

[Laszlo Papp]

> On Jan. 17, 2012, 10:28 p.m., David Faure wrote:
> > > "The kdeui module is unlikely welcome on mobile platforms"
> > 
> > Why is this review about adding stuff to kdeui, then? I don't get it. Either you're using it or you're not using it -- or the real reason is core/gui split in your libs/apps, which would be a valid point.

The desktop application uses kdeui.

KConfigDialog (QWidget *parent, const QString &name, KConfigSkeleton *config) -> It is now impossible to generate only one settings class inheriting KCoreConfigSkeleton, and use that in each frontend. I would not like to generate distinct settings classes without no real reasons.

Also, I discarded this patch because it is possible to make this API addition to 4.X. See my patch in frameworks.


- Laszlo


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


On Jan. 17, 2012, 3:54 p.m., Laszlo Papp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103716/
> -----------------------------------------------------------
> 
> (Updated Jan. 17, 2012, 3:54 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, like handsets; for instance Harmattan on N9. It
> would be nice to use the same settings code generation in certain cases for all
> the platforms since the additions of KConfigSkeleton on the top of
> KCoreConfigSkeleton are the font and color settings. These are currently not
> used in many 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; one with
> KConfigSkeleton argument type, and yet another with KCoreConfigSkeleton. It
> looks like a situation where the KCoreConfigSkeleton version was added later.
> 
> KConfigDialog does not have a constructor yet with KCoreConfigSkeleton argument
> type yet; it has probably somehow been missed so far. Changing the current
> constructor to KCoreConfigSkeleton usage is not possible in the 4.X major
> version because of the consequences (ABI breakage). Thereby, the freshly
> replacated constructor. The proper fix can be filed against frameworks where
> there is only one, and properly working constructor.
> 
> 
> Diffs
> -----
> 
>   kdeui/dialogs/kconfigdialog.h 2ac0eda 
>   kdeui/dialogs/kconfigdialog.cpp e815e54 
> 
> Diff: http://git.reviewboard.kde.org/r/103716/diff/diff
> 
> 
> Testing
> -------
> 
> On Archlinux (build test only)
> 
> 
> Thanks,
> 
> Laszlo Papp
> 
>

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