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" class does not inherit QObject.
Adding a virtual deconstructor is more or less mandatory, but QObject already
does that.
And the deconstructor has a header "implementation" but it is NOT inlined.
1. QObject has a virtual deconstructor and that flag cannot be withdrawn.
All derived classed have virtual deconstructos.
2. adding a deconstructor that does nothing is pointless - if the plugin needs
a deconstructor implementation, it can just add one.
Ok, I will remove this comment from interface. It will be up to
plugin how completion implement.
Please move it into the abook implementation and bonus points for correcting it
=)
This is a hack, IMHO. I'd prefer to split these into:
openAddContactWindow(const QString &mailAddress, const QString
&prettyName)
openEditContactWindow(const QString &mailAddress)
...
There could be problem, because Trojita does not know if email
address or contact name is already in addressbook or not.
I don't see why there needs to be two edit functions or special handling of
empty strings in the first place.
The abook gets an edit request for a mail address and a "pretty" name, checks whether a
matching contact is available, in doubt asks the user (there may be several "John Doe"s
out there) and opens it for editing.
If there's no match (eg. because the address is empty) it adds a new contact
and prefills it with the provided data.
Empty string is just a special case of unknown, but does not need sepcial
handling at all.
I think that plugin should decide if creating new contact or
editing existing.
So then plugin api needs only one function with "hints" for email
address and display name.
Kevin suggested that this method can be usefull for plugins.
Not if it's private. You wanted to protect it.
And do *not* inline functions of a plugin API - gets you ABI trouble for sure.
completionAvailable? OK, you prefer ...Result, so what about
completionResult?
...
Ok.
or what about just "completed()"?
Cheers,
Thomas
