[Kde-pim] [patch] Akonadi Control .desktop lookup based on XDG Base Dirs
Kevin Krammer
kevin.krammer at gmx.at
Thu Aug 23 13:13:41 BST 2007
On Thursday 23 August 2007, Volker Krause wrote:
> On Wednesday 22 August 2007 00:30:46 Kevin Krammer wrote:
> > Since Volker seems to like my patches I have another one to review ;)
> > Also touching a class with Tobias' copyright in it, so maybe he wants to
> > have a look as well. (server/control/agentmanager)
>
> And I like this one as well :)
Excellent :)
Comitted
> So far noone really cared about this stuff since it doesn't matter for
> developing, but it's extremely important for actual deployments.
Yes, I wanted to have this incorporated before any actual deployment, since at
this point we do not have to care about compatability yet.
Btw, a question on testing. Until know my changes were basically just touching
connection handling/setup and testing was pretty much just looking if Akonadi
control could start all service processes correctly when I launch
akonadiconsole.
However I am unsure how to test actual data transfer things. When I add a
vcard resource (on a copy of my std.vcf) in akonadiconsole, I see it listed,
there are config files generated in .config/akonadi but I am not sure where I
should be able to see or retrieve the contact data.
> > I have seen it referenced from CMakeLists.txt files in searchprovider,
> > resources and agents and I would have provided a patch for those as well,
> > but there is also a "share/apps" based path in
> > libakonadi/itemserializer.cpp and I am not sure if there are any cross
> > dependencies.
>
> This is needed by the plugin loader (libkdepim/pluginloader.h), which
> internally uses KStandardDirs. But this is just used on the client side
> (which has KDE dependencies anyway), so I don't think that's a problem.
Right, don't see a problem with this either.
I'll see what I can do with the searchprovider and agent .desktop files since
from the point of view of akonadi control it doesn't care how they are
implemented.
> Also, I would like to get rid of the duplicated xdgbasedirs.* files. I see
> two ways of doing this: putting it into libakonadiprotocol which contains
> shared qt-only code between client and server (and is currently well hidden
> in the libakonadi folder ;-) ) or simply adding the same source file to
> libakonadi and the server (which should work since we don't need to export
> the XdgBaseDir class).
Yes, this duplication is really bad. Any change has to be applied twice :(
Maybe another variant might be a "SVN symlink" (or whatever they are called,
like the admin/ directory in 3.5 branch)
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070823/bf6dfbec/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
More information about the kde-pim
mailing list