Hello,
here is first version of password interface:
#ifndef PASSWORD_INTERFACE
#define PASSWORD_INTERFACE
#include
#include
#include
class PasswordInterface : public QObject {
Q_OBJECT
public:
PasswordInterface(QObject * parent) : QObject(parent) {}
virtual ~PasswordInterface(
On Wednesday 19 June 2013 13:15:46 Jan Kundrát wrote:
> On Monday, 17 June 2013 14:15:33 CEST, Pali Rohár wrote:
> > So my question is: If Trojita will use QtKeychain library,
> > do we need qt interface plugin API for password storage in
> > Trojita?
>
> Hi Pali, sorry for delay -- I wanted to kn
On Wednesday 19 June 2013 12:15:30 Kevin Krammer wrote:
> Hi,
>
> On Wednesday, 2013-06-19, Pali Rohár wrote:
> > Hello,
> >
> > here is new version of interface. I added static function
> > formatAddress from
> > src/AbookAddressbook/AbookAddressbook.cpp as suggested
> > Kevin, removed const fro
On Wednesday, 19 June 2013 10:28:09 CEST, Pali Rohár wrote:
AddressbookInterface(QObject * parent) : QObject(parent) {}
virtual ~AddressbookInterface() {}
I wouldn't make these inline, but in the .cpp file. Perhaps it's not needed for
QObject, but the destructor is typically the first
On Wednesday, 19 June 2013 12:15:30 CEST, Kevin Krammer wrote:
One thing that might be interesting, depending on how the rest
of the code in
Trojita dealing with that interface looks like, is a "job"
interface for the
completion task (or for both asynchronous tasks).
That's a good advice for
Hi Pali,
a couple of comments:
- You're using a plain QString as a key, but do not define how this key is
going to be derived from the (type-of-account-IMAP-SMTP-etc, username). That's
not bad at the plugin level; the plugin perhaps doesn't need to know, and it's
possible that the existing key
On Thu, 20 Jun 2013, Jan Kundrát wrote:
That's a good advice for general purpose APIs, IMHO. However, in Trojita's
case, we are deliberately limiting the API of the contect plugin; there are
no "native contacts" classes encapsulating the contact details to pass
around, no concept of a "unique
On Donnerstag, 20. Juni 2013 10:52:05 CEST, David Lang wrote:
So please try and keep the addressbook plugin from being too Qt
specific and make it be something that can support a simple use
case like this or a simple local file.
Trojita uses Qt and the plugin interface will likely be the Qt o
On Thursday, 2013-06-20, Jan Kundrát wrote:
> On Wednesday, 19 June 2013 12:15:30 CEST, Kevin Krammer wrote:
> > One thing that might be interesting, depending on how the rest
> > of the code in
> > Trojita dealing with that interface looks like, is a "job"
> > interface for the
> > completion task
On Thursday 20 June 2013 10:47:27 Jan Kundrát wrote:
> On Wednesday, 19 June 2013 10:28:09 CEST, Pali Rohár wrote:
> > AddressbookInterface(QObject * parent) : QObject(parent)
> > {} virtual ~AddressbookInterface() {}
>
> I wouldn't make these inline, but in the .cpp file. Perhaps
> it's n
On Donnerstag, 20. Juni 2013 12:18:19 CEST, Pali Rohár wrote:
On Thursday 20 June 2013 10:47:27 Jan Kundrát wrote:
I look at qt plugins howto and there is also used inlined virtual
destructor: https://qt-project.org/doc/qt-4.8/plugins-howto.html
Because there mentioned "FilterInterface" clas
On Thursday, 2013-06-20, Pali Rohár wrote:
> On Thursday 20 June 2013 10:47:27 Jan Kundrát wrote:
> > On Wednesday, 19 June 2013 10:28:09 CEST, Pali Rohár wrote:
> > > AddressbookInterface(QObject * parent) : QObject(parent)
> > > {} virtual ~AddressbookInterface() {}
> >
> > I wouldn't ma
On Thursday, 20 June 2013 12:18:19 CEST, Pali Rohár wrote:
There could be problem, because Trojita does not know if email
address or contact name is already in addressbook or not.
I think that plugin should decide if creating new contact or
editing existing.
So then plugin api needs only one
On Thursday 20 June 2013 11:15:16 Jan Kundrát wrote:
> Hi Pali,
> a couple of comments:
>
> - You're using a plain QString as a key, but do not define how
> this key is going to be derived from the
> (type-of-account-IMAP-SMTP-etc, username). That's not bad at
> the plugin level; the plugin perhap
On Thursday, 2013-06-20, Jan Kundrát wrote:
> > void error(const QString &str);
>
> It isn't clear what this signal means and the receiver has no way of
> knowing to which request it is related. Remember, multiple requests for
> reading/writing passwords for multiple accounts could be in flig
On Thursday 20 June 2013 12:34:08 Thomas Lübking wrote:
> On Donnerstag, 20. Juni 2013 12:18:19 CEST, Pali Rohár wrote:
> > On Thursday 20 June 2013 10:47:27 Jan Kundrát wrote:
> >
> > I look at qt plugins howto and there is also used inlined
> > virtual destructor:
> > https://qt-project.org/doc/
On Thursday, 20 June 2013 13:57:20 CEST, Pali Rohár wrote:
And is needed default constructor for propagating parent?
AddressbookInterface(QObject * parent) : QObject(parent) {}
Yes -- constructors aren't propagated, so you still need one.
I disagree with Thomas on the destructor, though. In th
On Donnerstag, 20. Juni 2013 14:09:05 CEST, Jan Kundrát wrote:
sort-of-kinda-solves this via qobject_cast, but that's a band
aid. The lesson I've learned is to never use an inlined virtual
destructor.
I do not recall myself suggesting such ;-)
You can omit the empty virtual destructor (when
On Thursday, 20 June 2013 14:23:12 CEST, Thomas Lübking wrote:
I do not recall myself suggesting such ;-)
You can omit the empty virtual destructor (when inheriting from
a class with virtual destructor) - but not inline it (and
pointed out it's not inlined in the Qt plugin example either)
No
Hi,
I've just merged changes which remove the qmake-based setup. Trojita is now
supposed to be built by cmake.
Instructions on how to do this are at the website [1], but in a nutshell:
$ mkdir _build; cd _build
$ cmake -DCMAKE_BUILD_TYPE=debug ..
$ make -j4
$ ctest -j 4 --output-on-failure
$
Here is new version of password interface:
#ifndef PASSWORD_INTERFACE
#define PASSWORD_INTERFACE
#include
#include
#include
class PasswordInterface : public QObject {
Q_OBJECT
public:
enum Status {
Success = 0,
NoPassword,
Error,
};
PasswordInterface
Am Donnerstag, 20. Juni 2013 schrieb Jan Kundrát :
> Now I'm confused -- your mail suggests to omit the destructor altogether,
and at the same time you quote a document saying that one should always
include it. I agree with the quoted document :).
The important part here is that there /is/ a virt
Here is new version of addressbook interface:
#ifndef ADDRESSBOOK_INTERFACE
#define ADDRESSBOOK_INTERFACE
#include
#include
#include
class AddressbookInterface : public QObject {
Q_OBJECT
public:
AddressbookInterface(QObject *parent) : QObject(parent) {}
public slots:
/**
On Thursday, 2013-06-20, Pali Rohár wrote:
> * @short Return true if this plugin is valid and can be used (e.g this
> addressbook is installed and usable) **/
> virtual bool isValid() = 0;
Under what conditions would this return false?
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg
On Thursday 20 June 2013 15:49:40 Kevin Krammer wrote:
> On Thursday, 2013-06-20, Pali Rohár wrote:
> > * @short Return true if this plugin is valid and can be
> > used (e.g this
> >
> > addressbook is installed and usable) **/
> >
> > virtual bool isValid() = 0;
>
> Under what con
On Thursday, 20 June 2013 15:36:46 CEST, Thomas Lübking wrote:
The important part here is that there /is/ a virtual deconstructor in the
base class (where it /has/ to be if you don't want funny effects on
deconstruction)
It's not going away and every inheritance implemented deconstructor will be
On Donnerstag, 20. Juni 2013 16:53:15 CEST, Jan Kundrát wrote:
What I'm saying is that if you have class Foo: public QObject,
you have to declare and define a non-inlined virtual destructor
~Foo(). You're right that not marking it as "virtual" doesn't
matter. If there's no explicit ~Foo(), you
On Thursday, 20 June 2013 13:47:01 CEST, Kevin Krammer wrote:
Such a request context can easily be achieved by a "job" interface.
Just saying, I am not getting any money for selling job style interfaces ;-)
That's a big mistake -- if I was selling API designs, you'd be my first hire.
Pali, do
On Thursday, 20 June 2013 15:42:28 CEST, Pali Rohár wrote:
virtual void requestComplete(const QString &input, const
QStringList &ignores = QStringList(), int max = -1) = 0;
Either "requestCompletion" or "requestCompleting", but to me, "requestComplete" means something
very different than "
On Donnerstag, 20. Juni 2013 20:42:34 CEST, Jan Kundrát wrote:
You can also kill the ignores parameter, it doesn't appear to
be used. Thomas, do you have a comment on that, given that
originally added this?
The ignorelist is meant to have the addressbook skip entries already used in
TO/CC/BCC
On Thursday, 20 June 2013 21:13:17 CEST, Thomas Lübking wrote:
The ignorelist is meant to have the addressbook skip entries
already used in TO/CC/BCC/SENDER fields, what helps to limit the
maximum of entries, thus the popup short, and get faster to the
still relevant entries.
That's a good id
31 matches
Mail list logo
