[Kde-pim] Something for the weekend?

[Volker Krause]

Hi,

On Thursday 07 January 2010 15:19:17 Stephen Kelly wrote:
> 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 don't think any of our current backends supports non-tree hierarchies for 
tasks (or anything else). However, it can happen for mails:
- A sends mail to B and mailing list M
- B is subscribed to M and thus receives the mail twice
- B replies to one of them

Since the message id of A's and M's mail are the same, threading can't decide 
for one. Storage location doesn't matter as you can see an arbitrary set of 
mails in e.g. a virtual folder. So, B's mail would have both of them set as 
parent. Unlike the task case, the model can pick one at random here and 
doesn't need to show the item below both.
Besides duplicates I can't think of a case where we would have multuple 
parents, so semantically this is still a tree.

Also considering Thomas' examples I think we probably want a hybrid approach. 
The agent could add attributes for expensive calculations, such as finding 
all possible ancestors and ordering them (some might be missing in the 
displayed set). This would nicely fit into the Nepomuk feeder actually, which 
needs to do exactly the same to record the hierarchy so you can eventually 
search for and filter entire threads. This information is persistent (unless 
a better suited parent comes in of course, or the parent is deleted, another 
reason btw for putting the enitre ancestor chain in there) and the same for 
all views (as it contains semantic information, not the actually displayed 
tree, which depends on the selected item set).
The model would then do the rest, it most likely has an item id map already, 
so figuring out the best available parent in the display set is rather simple 
now. And it allows enough flexibility to add grouping etc. there as well.

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

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/20100108/268be52b/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/