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 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 back to some local overlay and merge those adressbooks, but by all means the "add to addressbook" action must not be visible or enabled if that's not possible.
I do not have any LDAP server, not know how LDAP working, what is needed for implementing LDAP client and also I do not planning this for GSoC.
Nobody said: please write each and every possible addressbook plugin, but the API needs to fit a wider branch than "suits me atm".
somebody will work on LDAP later, it will be possible to add new signals/jobs/methods to existing interface.
Please see the KDE ABI ref i linked previously. Adding a virtual is not possible. You /would/ have to rely on moc for that - what's apparently no option for the factory. I'll have a look at that later (weekend), but actually a factory should not be required - the few hints on the plugin can just be resolved from extern C. Bonus points if you can link what makes you believe you'd need a factory to create a singleton object.
Current interface only reflect what Trojita using
What is not enough when you want to encourage ppl. to write plugins and later. You also have to predict some possible limitations of plugins and provide an API to cover that. Designing a stable interface is different from "happy hacking". Hint: add *one* function "features()" returning a 32 or 64bit flag. Then add an enum as it can be extended anytime. This way we can ad tests for validity, editing, world domination etc. Cheers, Thomas
