Showing the folder's summary
About
The folder's summary is actually the most interesting view. Not really for the user and perhaps not for the application developer but definitely for the framework developer. It's this screen that consumes most memory and it's this screen that has to deal with most updates and actions.
For example when Push E-mail events happen, it's this screen where the user wants to see his E-mail arrive. It's also this screen that consumes most unsolicited bandwidth. You do have to somehow get the information that is visible, right?
When you have 50,000 messages, the summary is obviously not going to consume the entire messages as RAM memory. Nonetheless will we have to display the summary information of each message somehow. In Tinymail is this summary information placed in memory using mmap(). It consumes far less memory than most other E-mail clients do.
All that is nice and bla and stuff. I'm sure you as an application developer don't want to care about that. And you are right. What you care about is that it's easy to use. Easy to use it is.
Design
Setting the active folder, showing the summary
We learned at TMutMenuView that after the construction of TMutFolderView, we called tmut_folder_view_set_active_folder. Let's take a look!
We see that we create a ringtone player. That's not very important other than that this ringtone player is a TnyFolderObserver. We can observe changes in the folder, like when new messages arrive. That's of course an interesting moment to play a ringtone, for example.
We create a TnyGtkHeaderListModel which is a GtkTreeModel? implementation that Tinymail specifically implements to cope with huge amounts of rows and more precisely rows that contain summary data or TnyHeader instances.
Then we see tny_gtk_header_list_model_set_folder, which is the working horse that lifts all the hard work for you of setting up the model with a folder. We see that now we attach a TnyFolderMonitor. The folder monitor is a publisher subscriber design. The type is a TnyFolderObserver that publishes the changes it got notified of by the TnyFolder it subscribed to to a group of TnyList instances.
The TnyGtkHeaderListModel is such a TnyList implementation. Therefore it can be published to by the TnyFolderMonitor.
We add TnyList instances to the TnyFolderMonitor with tny_folder_monitor_add_list. Once we've done that, we simply refresh the TnyFolder with tny_folder_refresh_async. We also set the tree view's model.
New message arrivals will update our TnyGtkHeaderListModel, and that will update our GtkTreeView?. That's of course because a Model View Controller is a sort of publisher subscriber design too.
Opening a message
This is simple of course, we handle the "row-activated" signal with on_msg_selected. We get the summary instance that is selected (this will be a TnyHeader instance). Then we do something that is a little bit more difficult.
If the device is not online, we'll have to make it go online first. The tny_camel_account_set_online makes the account go online. The on_went_online is the callback, either we went online and the request didn't get canceled, or we failed to go online or it got canceled. If we failed to go online, a GError that is available in the parameters of the callback will be not NULL and will contain the error message.
If we did go online, we use tny_folder_get_msg_async. Back to on_msg_selected, if the device was online we just simply do tny_folder_get_msg_async immediately.
Those two tny_folder_get_msg_async calls both use tmut_folder_view_on_got_msg as callback. This is the callback when the message arrived. Again and just like the tny_camel_account_set_online API do we have either an error or a canceled situation. If neither an error occurred nor the request got canceled, we'll have the message.
In that case we make a TMutMsgView and we set the message to it so that this message view component displays it.
Congratulations, you just mastered the core piece of code of TMut.
