D28774: [KFontRequester] Port from QFontDialog to KFontChooserDialog
Ahmad Samir
noreply at phabricator.kde.org
Tue Apr 14 17:11:07 BST 2020
ahmadsamir added a comment.
In D28774#647157 <https://phabricator.kde.org/D28774#647157>, @dfaure wrote:
> I mean, the user can press cancel, that's when QColorDialog returns an invalid color.
> If there was a concept like an invalid font we could do the same here, but there's no such concept in QFont.
> So yep, no better way.
Looking at the code, if the user presses cancel, "theFont" is returned unchanged; seems pretty good to me:
int KFontChooserDialog::getFont(QFont &theFont, const KFontChooser::DisplayFlags &flags, QWidget *parent)
{
KFontChooserDialog dlg(flags, parent);
dlg.setObjectName(QStringLiteral("Font Selector"));
dlg.setFont(theFont, flags & KFontChooser::FixedFontsOnly);
const int result = dlg.exec();
if (result == Accepted) {
theFont = dlg.d->chooser->font();
stripRegularStyleName(theFont);
}
return result;
}
QFontDialog::getFont() returns a QFont, and one may pass a bool * to check the dialog result code:
QFont QFontDialog::getFont(bool *ok, const QFont &initial, QWidget *parent, const QString &title, FontDialogOptions options)
which is standard Qt behaviour from other dialogs/widgets that handle user yes/no use cases, IIRC.
The KFontChooer* approach is more "economical", the "initial" font and the font you get from the dialog if you press OK, are the same object, and the function returns the dialog result code. As some wise old builder once said "there's no right or wrong way to lay bricks, as long as it works".
REPOSITORY
R236 KWidgetsAddons
REVISION DETAIL
https://phabricator.kde.org/D28774
To: ahmadsamir, #frameworks, dfaure, cfeck
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200414/729afa63/attachment.html>
More information about the Kde-frameworks-devel
mailing list