fix(Notify): Use notification categories on Linux

[Pigpog]

With this change, events will notify using distinct categories.

Incoming calls use call.incoming
Friend and conference messages use im.received
Friend requests and group invites use the generic im
File transfer requests use the generic transfer

Since call notifications used the same exact code paths as friend message notifications, I had to change some logic in the newFriendMessageAlert function. It uses the notification body (text) being empty to determine that it is an incoming call.

Solves #424

---

This change is 

[Pigpog]

After more testing, I think more work is needed for notifications in general. If multiple notifications are generated, qTox simply changes the existing notification to say "3 message(s) from user". I imagine this is an artifact of snore-notify.

Additionally, incoming call notifications do not clear if the call has been cancelled.
And lastly, even after disabling "Play sound" in qTox notification settings, it still plays the qTox ringtone.

I think it would be best to delay merging this until these other issues can be addressed.

[Pigpog]

Ok so I went a bit out of scope here (meant to start a new branch, oops), but so far I've managed to fix most of the issues I listed before.
A new notification is sent for every event now. The notification titles and bodies have been reformatted accordingly. Disabling "Play sound" in settings truly stops all notification sounds from playing.
Still need to make it retract notifications in certain situations (call ring cancelled, chat window focused, maybe other cases).

[iphydf]

The main reason I used a single notification and made it update is the situation where you receive a lot of messages all at once. What happens with your change when someone spams a chat? In any case I think what we had was quite broken, so I'm happy to take a step back and simplify for now.

[Pigpog]

It would be kind of cool to group the messages from one contact into single notifications (without mixing categories). The notification generator would need to track the notification IDs in use for each contact. Perhaps we could use the contact number to make it super simple. I might have a poke at that.

I think we have a few options here:

1. Go back to grouping/summarizing all notifications
2. One notification per contact, appending new messages
3. One notification per event (my changes currently)

I dislike the first one because I am unable to read the messages in the notifications. One notification shared for everything is too conservative in my opinion.
The second one is a more modern behaviour and is nice for reducing clutter.
The third one is fine by me, telegram desktop acts this way and it causes no issues. Spam attacks can be vicious on Tox though, and this one adds to the impact. Perhaps we could rate limit notifications?

[nurupo]

What about making this a settings option - updating the existing notification on an event vs adding a new notification per event? Might not be possible to do on every platform, but sounds like it might be useful for the ones that support it.

[iphydf]

We're really focussing on Linux here. Other platforms use the Qt built-in thing, which doesn't allow notification fusing, categories, etc. at all. I do believe our best UX is going to be on Linux (and I'm very OK with that). For that, I think option 2 is best, but we can go ahead with 3 for the moment, and make 2 as an improvement on top of that (unless you want to do it now, I'm happy with that as well).

[Pigpog]

It might be best to keep this PR somewhat on track here and stick with individual notifications for now as you say.
I'm in for a git headache already with the mess I made

[Pigpog]

I'm just redoing all my commits at the moment, not very git-savvy

[Pigpog]

Reopening since I didn't mean to close

[Chiitoo]

I'm just redoing all my commits at the moment, not very git-savvy

Depending on the mess, probably most of the time you can use git rebase --interactive HEAD~11 (where 11 is a random number of commits I used as an example) to clean things up. :]

[Pigpog]

Ok that should be all of my changes back in place.
To recap, new notifications are sent for every event, the "Notify sound" setting now disables the ringtone and any other notification sound, and each type of notification is categorized per FreeDesktop's spec.

[Pigpog]

Looks like other platforms use notificationgenerator.. Should I go ahead and modify them to do single notifications as well?

EDIT: Looking at it again, the windows build test is failing due to an unused variable, but it is used in the very next line.

[iphydf]

Looks like other platforms use notificationgenerator.. Should I go ahead and modify them to do single notifications as well?

EDIT: Looking at it again, the windows build test is failing due to an unused variable, but it is used in the very next line.

That's because it's only used in assert, which gets removed in release builds. You can put a std::ignore = ... for unused parameters.

[iphydf]

/qtox/src/platform/desktop_notifications/desktopnotifybackend_noop.cpp:18:28: error: out-of-line definition of 'showMessage' does not match any declaration in 'DesktopNotifyBackend'
bool DesktopNotifyBackend::showMessage(const QString& title, const QString& message,
                           ^~~~~~~~~~~