On Sunday, 11 August 2013 11:57:59 CEST, Pali Rohár wrote:
Both plugins passes information in signals params. This is
unified. But only in ComposeWidget.cpp code I need sender()
because pointer of Job is removed from queue. This is needed
because ComposeWidget had sync API for completion and it was not
easy to rewrite code to use new async addressbook job without
sender().
Now I took a second look. I was under impression that you followed Kevin's
advice about always including the Job *job parameter in the jobs' signals.
However, looking at the actual code now
(pali/pali-gsoc:src/Plugins/AddressbookPlugin.h,
pali/pali-gsoc:src/Plugins/PasswordPlugin.h), it looks like these
parameters were removed. Is that right? If yes, why did you remove them?
Apologies if I'm missing something obvious.
And then I remove description from trojita settings.
Thanks for this.
I do not like this automagic idea of selecting plugins. I bet
that in some specific situation & configuration it will not work as
user expect...
That's a very good point -- shipping a code which is as robust as possible
makes a lot of sense, and limitting needless options is a way to increase
this robustness. However, in this situation, I'm worried about whether the
plugins will get any usage when they are disabled by default.
What do you propose?
I only need unique qstring identifier for each account. And this
string needs to be passed to each PasswordJob operation.
So until multiple account support is there, I can use unique
string "1" (now it is username). And then when multiple accounts
will be there you will pass account identifier instead "1". Ok?
Ah, I was under impression that the password backends actually could make
use of some better-structured data, like "this is a password for *John* for
his *IMAP* account at *example.org*". If this is wrong, i.e. if the
backends don't care about this data then, an "account ID" is enough.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
