Collated notifications and other improvements.
It'd be great if we could have some collation or summarizing of the notifications. The current notifications are fine for a regular private person, but when I look at the notifications of the Krita account, there's too many to really make sense of, especially when posting project releases.
Mastodon right now doesn't do anything with the notifications (beyond turning off notifications for people that you don't follow), so I think a client might be a good place to experiment with this.
For boosts and favourites:
I think a good place to start would be to collate notifications that are about the same post.
There's several ways of displaying this, like, for example, liked and boosts could be summarized like "The following people boosted X:" and then a list of avatars. This may however break down if a post goes properly viral and gets 200+ notifications.
Another might be a little report that says 'X amount of people have boosted/favourited Y'. The downside of this is that it's a bit unpersonal which may be unsuitable for a social network client.
So another way of doing this would be to tier it: If there's more that 10~ subsequent notifications, start collating with a list of avatars and if that value goes above... 50~ start creating a little report.
Mastodon also has support for time line markers in the notifications, which could be used to figure out which entries are new.
For mentions:
Given the default reply behaviour tends to use encourage mentions, it would be good if mentions that are replies on a post would be collated like "a, b and c replied to X".
Other:
Given it's a social media client it might be helpful to prioritize certain accounts in the notifications. This can be on the basis of heuristics (mutuals/following/follower/other), or by using a list that was configured by the account?
There's also other types of notifications besides boost/fav/reply, and I don't yet have strong opinions on them.
- Follows and follow requests are the most common and the web ui has a separate tab for the latter. It might be an idea to separate out follows as well, with the ability to follow back? Needs workshopping.
- status, polls and updates are a lot rarer than the rest and can be left alone, I think.
- admin notifications should prolly get their own column?
Technical:
So, I know this is gonna be a bit tricky to implement, because afaik the notifications are just a listview of the underlying model. On top of that, collation is much more intricate than the simple filtering/sorting proxymodel. I suspect it will need a custom QAbstractProxyModel, one that is able to either a) make collated notifications children of a parent QModelIndex (turning it into a tree model), or b) just keeps a list of indices that belongs with a collated QModelIndex so that mapFromSource and mapToSource may actually work.
Beyond that there's a lot of careful thought necessary when determining:
- what the timestamp for the given collated index is, so it doesn't cause hiccups when sorting.
- when and how to update the proxy model, given that it doesn't have dynamic update for this particular class.
- what happens when loadMore is triggered, etc.
I am in particular wondering if there's another KDE project that may have done something like this so we may learn from it.
Even though it will probably be tricky to implement and there's plenty of other stuff still to do, I do think it'd be really useful for us with .