[Kde-pim] Still having trouble creating akonadi resource

Stephen Kelly steveire at gmail.com
Sun Dec 28 23:45:12 GMT 2008


Hi,

I've been doing a bit more work on getting kjots to the point where it can
be akonadi powered.

http://websvn.kde.org/trunk/playground/pim/kjotsrewrite/

Patching akonadi is no longer necessary. Changes to akonadi are in the
akonadi-next directory. They'll be merged in when finished.

As it is, you can sort of run the kjotsrewriteapp application and it sort of
works. I've disabled any attempt at ordering in the model, but I'm sure
I'll be able to make that work. It's just getting in the way right now
though of the other issues.

The biggest problems I have right now are in the resource code and mainly
caused by not knowing the parent collection at various times when trying to
update harddisk stored data and things like that.

When I move an item from one collection to another with an itemmovejob, the
resource seems to get two notifications. It gets a collectionChanged for
the source, and the destination collection. However, as a collection
doesn't know its items, I don't think I can figure out in the
Resource::collectionChanged slot that an item move has occurred and modify
on-disk files. I don't know how I can get around this. Possibly an
itemCopyJob and a ItemDeleteJob in a transaction? I don't think that's a
very good solution.

Also, a Hash of parents for entities is maintained in the resource. This is
because Items don't know their parent. Additionally, I've found that
collection::parentRemoteId always returns an empty string from the
collection passed into the slot. So the hash is used there too. I'm not
sure if that's a bug, or I need to set something monitored in the change
recorder. The problem with this approach is that when a collection is moved
to a different parent, that corresponds to a collectionChanged for that
moved collection. However, the parentRemoteId in the hash in the resource
is still the previous parent. I can use that to figure out where the
collection should be moved from, but I can't know where it should be moved
to. Possibly this would be solved if Collection::parentRemoteId worked.

To see what I mean, run the app, and move the Bat Book from the Foo Book to
the Bar Book. The monitor handles this case, and the model updates
correctly, but the resource doesn't. Try to figure out how to move the line 

 <KJotsBook filename="bat.kjbook" />

from
http://websvn.kde.org/trunk/playground/pim/kjotsrewrite/kjots_common/data/foo.kjbook?view=markup

to
http://websvn.kde.org/trunk/playground/pim/kjotsrewrite/kjots_common/data/bar.kjbook?view=markup

using only the Collection::remoteId (In this case "bat.kjbook"). 

The whole idea of storing data in this resource in up for change if there's
a way that will work better with akonadi by the way. 


Nothing at all is set in stone yet because I'm still hitting large brick
walls with this stuff. I know I'll have to refactor it again anyway. I
still get the impression I'm using akonadi the wrong way here.


Any pointers?

Steve.


_______________________________________________
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