[Kde-pim] Something for the weekend?

[Stephen Kelly]

Hi,

One of the difficult problems we still don't yet have a generic solution for 
is that of turning a list of Akonadi::Items into a tree. This is needed for 
email threading for example, where kmail already has a specific solution. It 
would also be needed by an Akonadi port of KTimeTracker if it uses 
EntityTreeModel, KOrganizer for tasks/subtasks, zanshin, and there are 
probably a lot more uses of such a thing.

My attempt at a solution is (predictably) a proxy model, the 
KReparentingProxyModel.

http://api.kde.org/4.x-api/kdepim-
apidocs/akonadi/akonadi_next/html/classKReparentingProxyModel.html

http://steveire.wordpress.com/2010/01/06/testing-proxy-models-gets-easier-
again/

The idea would be to implement a subclass of it, something like 
Akonadi::ReparentingProxyModel which uses an Attribute to determine the 
required tree structure of the group of items. The proxy would fetch this 
attribute and use it in the implementation of the isDescendantOf method. The 
attribute would be set by an agent similar to the MailThreadingAgent.

This has a few consequences: Different applications might be showing 
different subsets of all of your emails or be threaded a different way, and 
so might require a different threading attribute.

I had an idea of a volatile attribute to solve this. Usually an attribute 
has a type() which is static, something like "ENTITYDISPLAYATTRIBUTE", and 
therefore one item can only have one attribute of any particular type. If we 
had volatile attributes we would instruct the agent to put the threading (or 
parenting) information into a an attribute with a type with a random number 
chosen by the proxy model such as "PARENTINGATTRIBUTE-6535" so that a 
different random number would be used for each appearance of the item in a 
different thread structure.

The disadvantage of this is that the attribute would potentially have to be 
cleared and recreated by the agent each time the application starts, or 
possibly keeping the attribute around and storing in KConfig which attribute 
names belong to which view etc and reusing that information. KMail currently 
has a cache of threading information which it persists so that it doesn't 
need to recalculate it each time.

The whole volatile attribute thing is probably not necessary, but I wanted 
to put my complete train of thought here so you see where I'm coming from.

Imagine a list of items needs to be represented as a tree like this:

- 4
- - 5
- - 6
- - - 8

And in another view or application, like this:

- 8
- - 5
- - 6
- 4

Note that items 5 and 6 are descendants of different parents in each view. 
Is there any existing application where that is possible? That is, where an 
item could be shown as a child of different items in a useful way in 
different applications?

As far as I know email threading will always have the same structure, even 
if sorting or filtering is applied. That is, if the above represents emails, 
8 would be a reply to 6 would be a reply to 4 in the first structure so the 
second would not be possible.

Also, in a task tree, I would imaging that if a task is a subtask of another 
task, then it can only be a subtask of one task and not multiple. Is that 
true?

Depending on context and dependencies between different projects I think it 
might not be. For example, 

Task: Build British Empire
- > Subtask: Buy some tea
- > Subtask: Invite the Queen around on Sunday

Task: Get to know the neighbours
-> Subtask: buy some tea
-> Subtask Send a flyer around about a tea party.

Here the task "Buy some Tea" is a subtask of two different tasks, depending 
on whether I'm in my "Build British Empire" activity or my "Get to know the 
neighbours" activity. Is that a realistic scenario in any existing kdepim 
app? Do we want to make that an easy thing to do with Akonadi?

If it isn't and we don't, it's all gravy. We can just use one persistent 
attribute as we normally do currently and extend the idea of caching 
threading from kmail to be more generic. Otherwise we might need another 
solution.

I'll add a discussion task for this to the Osnabruck wiki page. 

All the best,

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/