Set #2 of comments:
+ QAction *actionComposeMail = m_window->findChild<QAction
*>(QLatin1String("action_compose_mail"));
+ QAction *actionComposeDraft = m_window->findChild<QAction
*>(QLatin1String("action_compose_draft"));
...
+ QAction *actionReplyPrivate = m_window->findChild<QAction
*>(QLatin1String("action_reply_private"));
+ QAction *actionReplyAllButMe = m_window->findChild<QAction
*>(QLatin1String("action_reply_all_but_me"));
+ QAction *actionReplyAll = m_window->findChild<QAction
*>(QLatin1String("action_reply_all"));
+ QAction *actionReplyList = m_window->findChild<QAction
*>(QLatin1String("action_reply_list"));
This begs to silently fail some day -> make them private members of
GUI::MainWindow and TrojitaPart a friend.
+ m_window->show();
+
+ // Insert it to Kontact
+ setWidget(m_window);
The order seems wrong, ie. flicker or at least overhead prone (you show,
reparent auto-hides, then needs re-show)
+Comment=Kontact Trojita Plugin
lacks acute accent.
+class TrojitaPlugin : public KontactInterface::Plugin
+{
+ Q_OBJECT
+
+ public:
+ TrojitaPlugin(KontactInterface::Core *core, const QVariantList &);
+ ~TrojitaPlugin();
+
+ int weight() const { return 190; }
ounces? pounds? kilogram? ;-)
maybe add a comment what a "weight" of 190 means here.
void SMTP::sendMail(const QByteArray &from, const QList<QByteArray> &to, const
QByteArray &data)
{
emit progressMax(data.size());
emit progress(0);
emit connecting();
+ this->from = from;
+ this->to = to;
+ this->data = data;
+ if (!auth || !pass.isEmpty()) {
+ sendMailContinue();
+ return;
+ }
+ connect(this, SIGNAL(gotPassword()), this, SLOT(sendMailGotPassword()));
+ emit passwordRequested(user, host);
What if there're successive sendMail calls before the password turned in?
This from/to/data should be lists, resp (better) ONE list of containers holding
from/to/data (to ensure they're in sync)
Also the continue routine(s) should wipe the lists
+class ClearTextPasswordJob : public PasswordJob
+{
+ Q_OBJECT
+
+public:
+ enum Type {
+ Request,
+ Store,
+ Delete
+ };
enums are extendable (though i'm absolutely not sure about compilers here, we'd
have to research this)
-> you could likely move this into PasswordJob, have a barrier
enum Type {
Request = 0,
Store,
Delete,
UserType = 256
};
and in doubt
enum Type {
Foo = UserType + 1,
};
in some inheriting class
+void AkonadiAddressbookCompletionJob::result()
+{
+ NameEmailList completion;
+
+ const KABC::Addressee::List &list = job->contacts();
Since KABC is claimed deprecated, is there no replacement API?
+ Q_FOREACH(const KABC::Addressee &addr, list) {
+ Q_FOREACH(const QString &email, addr.emails()) {
+ if (!m_ignores.contains(email) && (email.contains(m_input,
Qt::CaseInsensitive) ||
+ addr.realName().contains(m_input, Qt::CaseInsensitive))) {
as you passes m_input into akonadi, do you really have to test the match here?
}
+ completion << NameEmail(addr.realName(), email);
+ if (m_max != 0 && completion.size() >= m_max)
+ break;
@Kevin
How are chances about having query restrictions in akonadi (esp. return amount,
there's little sense
for any completer to show more than a dozen entries after you typed "ke" what
might match some hundreds)
+void AkonadiAddressbook::openContactWindow(const QString &email, const QString
&displayName)
+{
+ // TODO
+#if 0
is this short-term todo or long term todo? (in latter case the feature should
not be announced until)
+void KDEAddressbookCompletionJob::doStart()
+{
+ NameEmailList completion;
+
+ const KABC::Addressee::List &list = m_ab->allAddressees();
Just looked it up. this BUILDS the list on every call.
Could it be necessary to off-thread this job (eg. for "bigger" addressboks)?
Maybe findByEmail + findByName are faster?
+void KDEAddressbookProcess::slotApplicationLoaded()
+{
+ QDBusPendingCallWatcher *watcher = static_cast<QDBusPendingCallWatcher
*>(sender());
+ watcher->deleteLater();
+ slotKaddressbookRunning();
+}
this is superfluous, you can bind the finished signal to
slotKaddressbookRunning() first and to deleteLater of the watcher second.
(while the other order should actually works as well since deleteLater defers
by one event cycle)
+void KDEAddressbookProcess::slotKaddressbookRunning()
+{
+ ...
+ QString uid;
+ KABC::Addressee::List list;
+
+ if (!m_displayName.isEmpty())
+ list = m_ab->findByName(m_displayName);
+ else if (!m_email.isEmpty())
+ list = m_ab->findByEmail(m_email);
+ else {
+ KABC::Addressee::List listNames = m_ab->findByName(m_displayName);
+ Q_FOREACH(const KABC::Addressee &addr, listNames)
+ Q_FOREACH(const QString &addrEmail, addr.emails())
+ if (m_email == addrEmail)
+ list << addr;
+ }
Does it make sense to build the list while waiting for dbus (or starting the
process)?
Just measure the time usually taken by the dbus response, starting the process
and building this list (for a reasonable amount of accounts)
+class KDEAddressbook : public AddressbookInterface
As mentioned before i guess this should always be KABCAddressbook instead to
avoid the implication KABC
would be the promoted KDE default. Kevin?
Cheers,
Thomas
