Simplify notification handling
ClosedPublic

Authored by nicolasfella on Jan 18 2019, 10:13 AM.

Details

Summary

Use QPointer for KNotification
Use ready signal for signalling updates

BUG: 400010

Test Plan

Spawned some notifications

Diff Detail

Repository
R224 KDE Connect
Branch
noti
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 7271
Build 7289: arc lint + arc unit
nicolasfella created this revision.Jan 18 2019, 10:13 AM
Restricted Application added a project: KDE Connect. · View Herald TranscriptJan 18 2019, 10:13 AM
Restricted Application added a subscriber: kdeconnect. · View Herald Transcript
nicolasfella requested review of this revision.Jan 18 2019, 10:13 AM
broulik added inline comments.Jan 18 2019, 10:15 AM
plugins/notifications/notification.cpp
84

Can't this be simplified to drop the update argument and just check for m_notification?

This method is only used in the constructor where m_notification is null anyway, and in update where you check for m_notification

84

Looks like it's "public API", so maybe not?

nicolasfella added inline comments.Jan 18 2019, 10:41 AM
plugins/notifications/notification.cpp
84

Good point. I actually think I can simplify things much more

broulik added inline comments.Jan 18 2019, 10:42 AM
plugins/notifications/notification.cpp
84

Indeed, I think the m_closed stuff also isn't neccessary anymore

  • Simplify a lot
nicolasfella retitled this revision from Use QPointer for notification to Simplify notification handling.Jan 18 2019, 1:22 PM
nicolasfella edited the summary of this revision. (Show Details)
albertvaka accepted this revision.Jan 21 2019, 3:42 PM
albertvaka added a subscriber: albertvaka.

LGTM, just two comments.

interfaces/notificationsmodel.cpp
271–272

I would keep the parameter and the TODO, or fix the dataChanged emit so it doesn't contain every row.

plugins/notifications/notification.h
74

Why Q_SCRIPTABLE?

This revision is now accepted and ready to land.Jan 21 2019, 3:42 PM
nicolasfella closed this revision.Jan 24 2019, 8:19 AM