/apps/evolution/mail/display/show_preview
/apps/evolution/mail/display/thread_list
These keys are no longer needed since we're storing the settings by
folder now in ~/.evolution/mail/config/state. To simplify things we use
hard-coded defaults: TRUE for PreviewVisible, FALSE for GroupByThreads.
Move the search interface to a new widget: EShellSearchbar
The current search rule is now stored in EShellView, and the search
context in EShellViewClass similar to GalViewCollection (since it's
class-specific, not instance-specific).
Also add a couple new signals to EShellView: "clear-search" and
"custom-search" ("custom" refers to an advanced search or a saved
search -- something more complex than a quick search).
Still working out a few kinks. The search entry is clearly trying to
be too many things. We need a different way of indicating that you're
looking at search results. Perhaps a search results banner similar to
Nautilus.
Now the backend specifies the data dir for the mail module. Obviously it uses
the same directory as it previously used, it's just that the responsibility for
defining that value has moved to a different place.
This allows modules to specify their own data dir in a flexible way without
having them hard-coded to the backend class name. For example, the data dir for
the mail backend should be specified by the mail session (eventually as an eds
daemon) and the vfunc will allow the shell to query that in a generic way.
After analyzing this again I'm confident we really don't need it.
The only state change is from FALSE to TRUE at startup, and that
one-time event happens while the mail shell backend is starting up
(see: e_shell_backend_start()).
If a need arises to query for this in the future I'll extend the
EShellBackend API with an e_shell_backend_started() function, but
for now there's no need.
This pushes the get_data_dir() API down to the right level. At present, it is
still implemented by querying the shell backend for the data dir / config dir.
But this should eventually be reversed (when mail is split off to EDS) so that
the mail daemon is the one responsible for the storage locations and the shell
backend queries the daemon for these values.
EMailBackend is an abstract subclass of EShellBackend that handles
online and offline modes and application shutdown. Placing this in
the shared mail library allows Anjal to reuse it. Evolution's mail
module further extends this class as EMailShellBackend.
Previously I was just using G_TYPE_POINTER. Use the boxed camel object type
from e-util.h instead. When camel-gobject lands, we'll use G_TYPE_OBJECT
instead.
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.
https://bugzilla.gnome.org/show_bug.cgi?id=604627
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.
https://bugzilla.gnome.org/show_bug.cgi?id=604627
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.
https://bugzilla.gnome.org/show_bug.cgi?id=604627
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.
https://bugzilla.gnome.org/show_bug.cgi?id=604627
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.
https://bugzilla.gnome.org/show_bug.cgi?id=604627
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.
https://bugzilla.gnome.org/show_bug.cgi?id=604627
EMailSidebar is a subclass of EMFolderTree that implements the state
saving and restoration feature from EMailShellSidebar. Placing this
in the shared mail library allows Anjal to reuse it.
