On Wednesday, 2013-07-10, Pali Rohár wrote: > I already wrote that if you want I will create akonadi plugin > too. So there is no problem that distributions will do not have > plugin using new kde api.
Sure, I was just commenting on the assumption that the goal was primarily to hook into people's KDE addressbook data on commonly used desktop distritbutions. > I do not care that kabc is marked as deprecated. On my notebook > it is faster than akonadi. If you do not want to see kabc plugin in > trojita master git repo I will of course respect it and will prepare > akonadi plugin. But you cannot force me to use akonadi plugin > instead this kabc, if akonadi will be still slower. Obviously I am not suggesting that you can't do something that you would like to do, I was merely giving an overview over the technologies involved and their positioning from an upstream's point of view. Naturally anyone on an old kdepim/kdepimlibs state can access their contact data through KABC, whether that is because it is an old or long term stable distribution or explicit package override is only details. Anyone on a recent stack (> 4.3)using an application which uses KABC is either accessing the data through the compatibility plugin or on a shrinking number of backends. Again, there is nothing wrong with writing as many plugins as possible, I was just asking for input on the goals regarding the GSoC work. My assumption was that "KDE integration" meant "on contemporary KDE versions". If the repository ends up with a legacy KDE plugin and a current KDE plugin then sure, why not, as long as both are working as expected :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
