We already use a generated interface in kstatusnotifieritem, but not in notifybypopup.
Compile-time checks++
code--
broulik |
Frameworks |
We already use a generated interface in kstatusnotifieritem, but not in notifybypopup.
Compile-time checks++
code--
Spawned, updated, closed notifications, triggered actions
No Linters Available |
No Unit Test Coverage |
Buildable 26534 | |
Build 26552: arc lint + arc unit |
src/notifybypopup.cpp | ||
---|---|---|
115 | Previously it would accept the signal from any service which I find odd, though. Could you maybe check git logs to see if there was a reason for this? | |
364 | You have watcher (which is parented to notification) and notification as contexts, but in the lambda you also access this. This looks dangerous. How about using this instead of notification as context object? | |
376 | This is QDBusPendingReply<QStringList> (or just auto...) | |
385 | Unrelated: I was wondering, do we actually monitor the notification service changing and make them dirty again? | |
388 | range for? |
src/notifybypopup.cpp | ||
---|---|---|
115 | git history until the frameworks split isn't really telling, I didn't bother looking further back |
src/notifybypopup.cpp | ||
---|---|---|
363 | I think we should do an error check and whether we got the correct argument count back but we previously also didn't do it, so probably fine |