GNOME Bugzilla – Bug 604627
Refactor mail-folder-cache to reduce dependencies
Last modified: 2009-12-15 20:47:14 UTC
mail-folder-cache is currently just a loose collection of functions that make up a pseudo-object. I would like to refactor it to make it a proper GObject. This way it can emit signals, which will allows us to remove the hard dependencies from the folder cache to other objects such as the default shell, the EMFolderTreeModel, etc. Then the interested objects can just listen for the signals and 'pull' the data rather than having the folder cache responsible for pushing updates to every other object.
Created attachment 149779 [details] [review] Make the mail folder cache a proper GObject mail-folder-cache previously was a bit of a pseudo object (sort of a singleton) that operated on some file static data. This commit re-factors things so that it is a proper class named MailFolderCache. At the moment, this doesn't gain us much, but in the future, it will allow us to add signals, etc so that we can de-couple a lot of the interdependencies in here. This is essentially a pre-requisite to splitting up a lot of the mail backend stuff.
Created attachment 149780 [details] [review] Add documentation to clarify mail-folder-cache functionality Added a bunch of gtk-doc documentation as well as a variety of small comments in the code. Also added documentation and renamed a couple of mail_vfolder_* functions that are only used by mail-folder-cache to make things a lot more understandable.
Created attachment 149781 [details] [review] Add signals to MailFolderCache for common events This will allow us to decouple ourselves from some of the current dependencies, such as the folder treemodel, the shell, etc. This just defines the signals, the next step is to refactor things and actually make other classes use them. We need one additional signal yet related to indicating the new unread emails, but that one will require a little more thought I think.
Created attachment 149782 [details] [review] Remove mail-config, vfolder, and filter deps from mail-folder-cache Instead of pushing the updates to the right places, the folder cache simply emits the appropriate signals and other objects are responsible for listening and handling them appropriately. This allows us to cut down the dependencies of MailFolderCache significantly, which is a huge step towards allowing us to split it off for the backend. Another nice thing about this is that it allows us to trim a lot of 'public' api from the filter, vfolder, and config classes that were only used by the cache. Now that stuff can all be internal since they're pulling changes rather than having the changes pushed. The last remaining problematic dependency in MailFolderCache is EmFolderTreeModel. That is next on the chopping block.
Created attachment 149783 [details] [review] MailFolderCache: add signal for updated unread counts Emit a signal when we have an updated unread count for a folder rather than pushing the update directly to a particular treemodel. This doesn't yet remove the dependency on EMFolderTreeModel, but it's a first step.
Created attachment 149784 [details] [review] Add MailFolderCache::folder-changed signal Yes, this signal is kind of an ugly monster. I'm not sure how to improve this significantly. But this commit removes the last EMFolderTreeModel and EShell dependencies from MailFolderCache, which is a big step towards splitting off the backend.
This looks awesome! And given that you even wrote API docs, I'd say go ahead and commit this when you feel it's ready. Just be mindful of the release coming up on Monday and make sure this has a little time to settle in.
OK, I changed the signals to use the CamelObject boxed type instead of G_TYPE_POINTER and pushed it to git so that it has a chance to have a bit of testing before release day.