Refactor Collection from melib to hold what folders have what envelopes.
Frontend accounts will now have a FolderEntry for each logical folder
and will unify many Account fields into one and eliminate a lot of
duplicate/dead code.
Use FolderHash directly as a cursor type for folders within an account
isntead of having a usize (being the order of the folder within the
account) and figuring out the folder_hash everytime it's needed.
Add OfflineListing for offline accounts and AccountStatusChange event.
Subscription status was checked/modified in various places, whereas now
the universal truth is the `BackendFolder::is_subscribed()` method set
by the backend when a folder is created. The `Account` struct passes a
closure to the backend constructor that determines whether the folder is subscribed or not according to the user configuration.
- If subscribed_folders field is empty, then all folders are subscribed.
- OR check explicit folder configuration
- OR check if folder path matches to a glob in subscribed_folders.
`DisplayMessage` messages are for user input responses (eg errors for
user actions). They now appear as floating boxes in the bottom right
corner of the UI and can be browsed with Alt('<') and Alt('>')
No logical reason for it not to be in the terminal module anymore (the
set_and_join* functions predate the terminal module which is why they
weren't there to begin with).
Merge ui crate with root crate.
In preparation for uploading `meli` as a separate crate on crates.io.
Workspace crates will need to be published as well and having a separate
`ui` crate and binary perhaps doesn't make sense anymore.
UIEvent::StartupCheck was meant to notify the UI that a folder had made
progress and polling its async worker would return a
Result<Vec<Envelope>>. However the StartupCheck was received by
MailListing components which called account.status() which did the
polling. That means that if the polling got back results, the listing
would have to call account.status() again to show them. This is a
problem in configurations with only one account because there aren't any
other sources of event to force the listing to recheck account.status()
A new event UIEvent::WorkerProgress will do the job of notifying an
Account to poll its workers and the account will send a startupcheck if
it has made progress. That way the refresh progress is as follows:
Worker thread sends WorkerProgress event -> State calls appropriate
account's account.status() method -> account polls workers, and if there
are new results send StartupCheck events -> State passes StartupCheck
events to components -> Listings update themselves when they receive the
event
1. spawn thread to send ThreadPulses to the main event loop that "parks" until unparked from State
2. State unparks thread if there are accounts that are offline
3. thread sends ThreadPulse and parks again
4. State checks accounts again and so on.
meli --test-config PATH tests a configuration file for syntax issues or missing options.
Caveat: right now undefined options/values do not return an error.
Backend specific options are also not validated.
Make startup methods return Results so that the main binary can exit
cleanly instead of using std::process::exit from arbitrary positions,
which exits the process immediately and doesn't run destructors.
Emulate a terminal within meli. In the next commit it will be used to
embed an editor in the composing tab.
This is a non-complete xterm emulation that has some bugs.