[Kde-pim] [patch] Akonadi Control .desktop lookup based on XDG Base Dirs

[Volker Krause]

On Thursday 23 August 2007 14:13:41 Kevin Krammer wrote:
> 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.

right

> 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.

The browser tab in akonadiconsole should show you a folder for the vcard 
resource, containing all you contacts. If that's not the case, try restarting 
akonadiconsole and check the browser tab again, maybe the change notification 
is broken and the view is not updated correctly.

> > > 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)

I used symlinks for imapparser.* before, which the windows guys didn't like. 
But I think you are referring to svn:external, which AFAIK only works for 
directories and requires a full svn url (ie. anonsvn, so that everyone can 
actually access it). But duplicating the file shouldn't be needed in the 
first place, cmake doesn't require the sources to be in the same place.

regards
Volker
-------------- 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/20070824/23a2b520/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/