27;octubre de 2014, a les 22:22:12, Jeremy Whiting va escriure:
>> Hello,
>>
>> Is there a way to have custom settings mixed with kcfg_ type settings
>> in a KConfigDialog? Kanagram does this, but it only works when another
>> kcfg_ named widget changes too. The combo
El Dilluns, 27 d'octubre de 2014, a les 22:22:12, Jeremy Whiting va escriure:
> Hello,
>
> Is there a way to have custom settings mixed with kcfg_ type settings
> in a KConfigDialog? Kanagram does this, but it only works when another
> kcfg_ named widget changes too. The comb
Hello,
Is there a way to have custom settings mixed with kcfg_ type settings
in a KConfigDialog? Kanagram does this, but it only works when another
kcfg_ named widget changes too. The combobox to select which language
to use gets saved to disk by a slot that's connected to
KConfigDia
o 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
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
> arg
.
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
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 someh
ntly 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 KConfi
zes 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
sing it -- or the real reason is
> > core/gui split in your libs/apps, which would be a valid point.
>
> Laszlo Papp wrote:
> The desktop application uses kdeui.
>
> KConfigDialog (QWidget *parent, const QString &name, KConfigSkeleton
> *config) -> It i
sing 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 inherit
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
> 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
>
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
org/r/101409/
> ---
>
> (Updated May 21, 2011, 11:03 a.m.)
>
>
> Review request for kdelibs.
>
>
> Summary
> ---
>
> The documentation of KConfigDialog::addPage() is not very detailed about the
> parameter "pixm
---
Updated diff, using the text from Aaron.
Summary
---
The documentation of KConfigDialog::addPage() is not very detailed about the
parameter "pixmapName". This patch adds to the documentation that it is
possible to simply pass the KDE icon name instead of the pixmap pa
org/r/101409/
> ---
>
> (Updated May 21, 2011, 11:03 a.m.)
>
>
> Review request for kdelibs.
>
>
> Summary
> ---
>
> The documentation of KConfigDialog::addPage() is not very detailed about the
> parameter "pixmapName". This patch adds to the document
request for kdelibs.
>
>
> Summary
> ---
>
> The documentation of KConfigDialog::addPage() is not very detailed about the
> parameter "pixmapName". This patch adds to the documentation that it is
> possible to simply pass the KDE icon name instead of the pixmap
KConfigDialog::addPage() is not very detailed about the
parameter "pixmapName". This patch adds to the documentation that it is
possible to simply pass the KDE icon name instead of the pixmap path.
This addresses bug 273723.
http://bugs.kde.org/show_bug.cgi?id=273723
Diffs
-
kde
19 matches
Mail list logo
