Differential D28295 Diff 79104 src/knotificationjobuidelegate.cpp

Changeset View

Standalone View

src/knotificationjobuidelegate.cpp

This file was added.

1		/* This file is part of the KDE Frameworks
2		Copyright (C) 2020 Kai Uwe Broulik <kde@broulik.de>
3
4		This library is free software; you can redistribute it and/or
5		modify it under the terms of the GNU Library General Public
6		License version 2 as published by the Free Software Foundation.
7
8		This library is distributed in the hope that it will be useful,
9		but WITHOUT ANY WARRANTY; without even the implied warranty of
10		MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
11		Library General Public License for more details.
12
13		You should have received a copy of the GNU Library General Public License
14		along with this library; see the file COPYING.LIB. If not, write to
15		the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
16		Boston, MA 02110-1301, USA.
17		*/
18
19		#include "knotificationjobuidelegate.h"
20
21		#include <QString>
22
23		#include <KJob>
24		#include <KNotification>
25
	kossebauUnsubmitted Done Not using a nested class `Private` but a normal separate one like here to be named `KNotificationJobUiDelegatePrivate` seems more simple, avoids the need for things like Q_DECL_HIDDEN. At least recently most code uses the latter, so would be good to standardize on that. kossebau: Not using a nested class `Private` but a normal separate one like here to be named…
	broulikAuthorUnsubmitted Not Done I thought we wanted to migrate towards nested `Private` class? :0 broulik: I thought we wanted to migrate towards nested `Private` class? :0
	dfaureUnsubmitted Not Done I don't remember any past discussion about this, but as I discovered in KIO commit 3d2330968b, nested Private classes have the problem that you can't forward-declare them elsewhere in order to make them friends of another class. What would be the arguments in favour of nested Private classes? All I see is the risk of forgetting Q_DECL_HIDDEN, incompatibility with Q_D/Q_Q macros and more generally, inconsistency with Qt, plus the friend problem above. dfaure: I don't remember any past discussion about this, but as I discovered in KIO commit 3d2330968b…
	ahmadsamirUnsubmitted Not Done Someone should update the part about the nested Private classes https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C++#Using_a_d-Pointer ahmadsamir: Someone should update the part about the nested Private classes https://community.kde.
26		class KNotificationJobUiDelegatePrivate
27		{
28		public:
29		void showNotification(KNotification::StandardEvent standardEvent, const QString &text);
30
31		QString description;
32		};
33
	dfaureUnsubmitted Done remove? dfaure: remove?
34		void KNotificationJobUiDelegatePrivate::showNotification(KNotification::StandardEvent standardEvent, const QString &text)
35		{
36		KNotification::event(standardEvent, description, text);
37		}
38
39		KNotificationJobUiDelegate::KNotificationJobUiDelegate()
40		: KJobUiDelegate()
41		, d(new KNotificationJobUiDelegatePrivate)
42		{
43		}
44
45		KNotificationJobUiDelegate::~KNotificationJobUiDelegate() = default;
46
47		bool KNotificationJobUiDelegate::setJob(KJob *job)
48		{
49		const bool ok = KJobUiDelegate::setJob(job);
50
51		if (ok) {
52		connect(job, &KJob::description, this, [this](
53		KJob *, const QString &title, const QPair<QString, QString> &, const QPair<QString, QString> &
54		){
55		d->description = title;
56		});
57		}
58
59		return ok;
60		}
61
62		void KNotificationJobUiDelegate::showErrorMessage()
63		{
64		if (job()->error() == KJob::KilledJobError) {
65		return;
66		}
67
68		d->showNotification(KNotification::Error, job()->errorString());
69		}
70
71		void KNotificationJobUiDelegate::slotWarning(KJob *job, const QString &plain, const QString &rich)
72		{
73		Q_UNUSED(job);
74		Q_UNUSED(rich);
75
76		if (isAutoErrorHandlingEnabled()) {
77		d->showNotification(KNotification::Notification, plain);
78		}
79		}
80
81		#include "knotificationjobuidelegate.moc"