On Freitag, 21. Juni 2013 17:25:56 CEST, Kevin Krammer wrote:
Hmm, how often does it check that, or is a plugin only ReadOnly if it can
never ever write, e.g. addressbook file on a read-only optical drive?
I'd say, a simple member return will do.
The plugin can either write or not by backend design or backend or plugin
option.
Ie. you either "return true;" "return false" or "return m_canWrite;" where
m_canWrite can be obtained from a config file or server capabilities on init.
Whether the write will succeed (eg. because you went offline or the user silently
chmod -w) is a different matter. If this can be expected to happen, i'd say it's the
plugins duty to cache the values and sync them whenever possible, or ultimately
inform the user that writing is atm. not possble because of <very specific reason
of temporary failure here>
I'd say whenever opening the desktop.
The addressbook can then either return a cached value or a static value or can
perform an update (initially setting it disabled and enable the action if
possible) - depending on the plugin nature.
/**
* @short Return true if contact exists in addressbook
**/
virtual bool contactExist(const QString &email) const = 0;
That looks like something that shouldn't be synchronous.
I'd frankly rather ask: why in the first place?
The GUI does not have to reflect the API, so there's no need to have distinct
functions openContactWindow() and openAddContactWindow()
Trojitá *announces* editing only if supported by the backend but it can just call the plugin to
openContactWindow(HumanName, Mail) - if the plugin says: "not editable". this call comes
for a present account (or the plugin says "No Contact for Eric Cartman found"), otherwise
the account is checked in the plugin and in doubt added.
This has the advance of not having to ask the server twice ("exists contact" + "add it" |
"edit it") to get the relevant dialog on screen (being a void call anyway, thus can in doubt spawn
a new thread/process and return early)
Cheers,
Thomas
