On Montag, 5. August 2013 17:20:16 CEST, Jan Kundrát wrote:
It might be better to separate this into two classes.
One that implements the addressbook and one that implements
the interface using an instance of that class.
One reason is that anyone creating new plugins will look at
the existing
On Monday 05 August 2013 18:25:23 Jan Kundrát wrote:
> On Saturday, 29 June 2013 10:26:26 CEST, Pali Rohár wrote:
> >> - What's the point of storing the plugin path in the
> >> settings? Check how the localization is loaded to see what
> >> I mean with the path discovery.
> >
> > I see that trojit
On Saturday, 29 June 2013 10:26:26 CEST, Pali Rohár wrote:
- What's the point of storing the plugin path in the settings?
Check how the localization is loaded to see what I mean with
the path discovery.
I see that trojita loading localization from PKGDATADIR. But I do
not see where it is defi
On Monday, 8 July 2013 16:05:28 CEST, Kevin Krammer wrote:
- AbookAddressbook has lots of public API that is not in
AddressbookInterface (e.g. model).
It is needed in AddressbookInterface (somewhere for Trojita)? Or
where is problem? AbookAddressbook is also used by be.contacts
standalone appli
On Monday, 2013-07-08, Pali Rohár wrote:
> On Saturday 29 June 2013 16:02:59 Kevin Krammer wrote:
> > - AbookAddressbook has lots of public API that is not in
> > AddressbookInterface (e.g. model).
>
> It is needed in AddressbookInterface (somewhere for Trojita)? Or
> where is problem? AbookAddre
On Saturday 29 June 2013 16:02:59 Kevin Krammer wrote:
> On Saturday, 2013-06-29, Pali Rohár wrote:
> > > - Not sure whether you need to #include ;
> > > perhaps a forward declaration is enough (haven't checked,
> > > might be wrong)
> >
> > This will not work, because in class is full QPointer ob
On Saturday, 2013-06-29, Pali Rohár wrote:
> > - Not sure whether you need to #include ; perhaps a
> > forward declaration is enough (haven't checked, might be
> > wrong)
>
> This will not work, because in class is full QPointer object -
> not pointer or reference.
Could still be possible to for
On Saturday 29 June 2013 12:00:47 Caspar Schutijser wrote:
> Hi Pali,
>
> On Saturday, June 29, 2013 10:26:26 AM CEST, Pali Rohár wrote:
> > Ok, is there any document describing trojita coding style?
>
> There is this document:
>
> https://projects.flaska.net/projects/trojita/wiki/Coding_style
>
Hi Pali,
On Saturday, June 29, 2013 10:26:26 AM CEST, Pali Rohár wrote:
Ok, is there any document describing trojita coding style?
There is this document:
https://projects.flaska.net/projects/trojita/wiki/Coding_style
Best regards,
Caspar Schutijser
On Friday 28 June 2013 20:07:55 Jan Kundrát wrote:
> On Friday, 28 June 2013 11:43:32 CEST, Pali Rohár wrote:
> > Here is git repository (branch master) with my gsoc code:
> > http://quickgit.kde.org/?p=clones/trojita/pali/trojita.git
>
> Hi Pali, wow, looks like you've been busy in the meanwhile
On Friday, 28 June 2013 11:43:32 CEST, Pali Rohár wrote:
Here is git repository (branch master) with my gsoc code:
http://quickgit.kde.org/?p=clones/trojita/pali/trojita.git
Hi Pali, wow, looks like you've been busy in the meanwhile -- I'm happy to see
that. It would be even cooler if you let
On Friday, 2013-06-28, Jan Kundrát wrote:
> On Friday, 28 June 2013 15:17:46 CEST, Thomas Lübking wrote:
> > Error logging or similar can connect a generic "Job::error(int
> > id, QString desc)" slot and you don't have to define the
> > signals, resp. members/getters lilke m_/id() multiple times.
>
On Friday, 28 June 2013 15:17:46 CEST, Thomas Lübking wrote:
Error logging or similar can connect a generic "Job::error(int
id, QString desc)" slot and you don't have to define the
signals, resp. members/getters lilke m_/id() multiple times.
I still don't see a big benefit in this. It would ma
On Freitag, 28. Juni 2013 15:06:41 CEST, Jan Kundrát wrote:
On Friday, 28 June 2013 14:31:21 CEST, Thomas Lübking wrote:
The point about a common class is to allow generic job
handlers as well as not to have to write the same stupid
"stop", "cancelled", "finished" interface multiple times.
Sp
On Friday, 28 June 2013 14:31:21 CEST, Thomas Lübking wrote:
The point about a common class is to allow generic job handlers
as well as not to have to write the same stupid "stop",
"cancelled", "finished" interface multiple times.
Speaking about the KJob, I'd prefer to keep the interface small
On Freitag, 28. Juni 2013 14:20:33 CEST, Pali Rohár wrote:
On Friday 28 June 2013 14:10:35 Thomas Lübking wrote:
On Freitag, 28. Juni 2013 12:35:19 CEST, Kevin Krammer wrote: ...
Now I'm rewriting addressbook requests to use jobs. But I do not
think that we need common interface for both addr
On Friday 28 June 2013 14:10:35 Thomas Lübking wrote:
> On Freitag, 28. Juni 2013 12:35:19 CEST, Kevin Krammer wrote:
> >> http://quickgit.kde.org/?p=clones/trojita/pali/trojita.git
> >
> > I would still recommend to do at least the completion task
> > in form of a job.
>
> I frankly was under th
On Freitag, 28. Juni 2013 12:35:19 CEST, Kevin Krammer wrote:
http://quickgit.kde.org/?p=clones/trojita/pali/trojita.git
I would still recommend to do at least the completion task in form of a job.
I frankly was under the impression there was agreement on this anyway?
ALso I definitly saw so
On Friday, 2013-06-28, Pali Rohár wrote:
> And I merged factory class from password and addressbook
> interfaces to one, because both have same functions. It is easier
> to match correct trojita plugin in trojita plugin loader.
>
> Here is git repository (branch master) with my gsoc code:
> http:
On Wednesday 26 June 2013 19:38:03 Jan Kundrát wrote:
> On Friday, 21 June 2013 22:36:48 CEST, Pali Rohár wrote:
> > virtual qint64 features() const = 0;
>
> I am no expert on this part of the language, but wouldn't a
> quint64 make more sense here? Presumably, one wants to use it
> like this:
On Friday, 21 June 2013 22:36:48 CEST, Pali Rohár wrote:
virtual qint64 features() const = 0;
I am no expert on this part of the language, but wouldn't a quint64 make more
sense here? Presumably, one wants to use it like this:
if (plugin->features() & AddressbookInterface::ReadOnly) ...
Here is new version:
#ifndef ADDRESSBOOK_INTERFACE
#define ADDRESSBOOK_INTERFACE
#include
#include
#include
#include
#include
#include
class AddressbookInterface : public QObject {
Q_OBJECT
public:
enum Feature {
ReadOnly = 1
};
/**
* @short Return implement
On Friday 21 June 2013 19:15:41 Thomas Lübking wrote:
> 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 me
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 d
On Friday, 2013-06-21, Pali Rohár wrote:
> I added virtual features() method and changed open contact window methods.
> Now there is method openContactWindow() for existing contact and method
> openAddContactWindow() for adding new contact. Trojita should check if
> contact is already addressbook b
I added virtual features() method and changed open contact window methods. Now
there is method openContactWindow() for
existing contact and method openAddContactWindow() for adding new contact.
Trojita should check if contact is already
addressbook by contactExist() and then decide if will show
On Friday, 2013-06-21, Jan Kundrát wrote:
> On Friday, 21 June 2013 12:17:38 CEST, Pali Rohár wrote:
> > So if addressbook plugin using client/server model (not only
> > akonadi!), it can check if server is installed and enabled in
> > isValid() method.
>
> And hence my remark about the LDAP serve
On Friday, 21 June 2013 12:20:27 CEST, Thomas Lübking wrote:
What if the user somehow wants to store an address, but the
current plugin does not provide that?
You cannot announce "add to adressbook" and then present the
user an uneditable dialog.
Ideally, trojitá would resolve that by falling ba
On Friday, 21 June 2013 12:17:38 CEST, Pali Rohár wrote:
So if addressbook plugin using client/server model (not only
akonadi!), it can check if server is installed and enabled in
isValid() method.
And hence my remark about the LDAP server. The current draft of the API is
sufficient for check
On Freitag, 21. Juni 2013 12:17:38 CEST, Pali Rohár wrote:
On Friday 21 June 2013 12:06:52 Thomas Lübking wrote:
On Freitag, 21. Juni 2013 11:10:49 CEST, Pali Rohár wrote: ...
With akonadi I mean: There are akonadi client libraries and
akonadi server (process). You need to have akonadi client
On Freitag, 21. Juni 2013 11:17:24 CEST, Pali Rohár wrote:
Hm, I think it is not needed. In plugin interface we need only
function which open contact window. And there could be edit
button or window will be itself editable (like kaddressbook or
internal trojita addressbook).
What if the user
On Friday 21 June 2013 12:06:52 Thomas Lübking wrote:
> On Freitag, 21. Juni 2013 11:10:49 CEST, Pali Rohár wrote:
> > With isValid() I mean if all required
> > programs/libraries/other dependences for plugin are
> > installed.
>
> Package resolution is a distro job (in the linux/bsd world)
> ie.
On Freitag, 21. Juni 2013 11:10:49 CEST, Pali Rohár wrote:
With isValid() I mean if all required programs/libraries/other
dependences for plugin are installed.
Package resolution is a distro job (in the linux/bsd world) ie. a *plugin* that
requires akonadi should simply not be installed when
Hello, here is new version of addressbook interface
#ifndef ADDRESSBOOK_INTERFACE
#define ADDRESSBOOK_INTERFACE
#include
#include
#include
#include
#include
#include
class AddressbookInterface : public QObject {
Q_OBJECT
public:
AddressbookInterface(QObject *parent) : QObject(par
On Thursday 20 June 2013 22:21:54 Jan Kundrát wrote:
> 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, a
On Thursday 20 June 2013 20:42:34 Jan Kundrát wrote:
> 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"
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
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 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 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 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 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, 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
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, 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
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 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 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 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, 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 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 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 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 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 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 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
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
57 matches
Mail list logo
