[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