See issue #414 and !498

Evangelos Ribeiro Tzaras authored Oct 30, 2020 and Mohammed Sadiq committed Nov 01, 2020

This commiti aims to close #414

Mohammed Sadiq authored Jul 09, 2020 and Sebastian Krzyszkowiak committed Oct 31, 2020

When a new chat is created, it is added to the chat list.  If
the user goes back to chat list without adding any chat message,
hide the newly created chat as the user likely cancelled the chat.

This lists the form-factors the app was designed for in the AppStream
data and the desktop entry.

The username of the message author name was not set
and thus the database were being filled with empty
names

This was broken in b116a95f

This was the case for a long time.  When message-row
was written, this was left out accidently, but not
noticed as we were not setting message author (and
thus the avatar was always hidden)

Fixes: d6ffe9de ("Release version 0.1.16")

And adapt to API changes

So that it can be used for all type of accounts

And adapt to API changes.

chatty_pp_account_is_sms() was using only chatty-item API.
So moving it to chatty-item shall allow us to use the API
in more cases, and not just for accounts

And move the old chatty-chat to chatty-pp-chat

So that we can use this as the base class for chats

Use sorted_chat_list, which is now more appropriate.

We now make use of ui_data for tracking various objects.  And
so we no longer have to lookup in lists to find the objects.

Don't differentiate between IM and chats.  Use a single liststore
for any type of chats, and so we no longer require im_list, and
related helper models.

We don't have to list IM chats as buddies are listed separately

We were using the wrong variable to check for match
resulting in surprising results

So that we don't have to handle memory [de]allocations.

Use chatty_manager_add_chat() instead of chatty_manager_add_conversation()
So that we have one less API. Also add_chat() adds chat to the right
list instead of blindly adding to im_list, which was how it was done
until now.

libpurple may remove a node to simply add it again. It's hard
to know if the removal happened simply to add it again or not.

When an actual deletion happen, the associated PurpleConversation
is deleted, and so tracking PurpleConversation alone can make this
process simpler.