Thoughts and Questions on the Nepomuk Models

[David Edmundson]

Heya, as the nepomuk models are starting to come into fruition I
thought I'd give some input/ask a lot of annoying questions about them
from the POV of someone who uses the models a lot.

- In the contact list we've had quite a few issues with knowing what
type any given Index is.
i.e in the delegate we had some overly complex code to find out if
it's painting a contact, account header, or a group header. It would
be great if we could fix this from the start, some sort of
"WhatAmIRole".

- For use in QML could you call setRoleNames in your model
constructors. It basically exposes your enum of role types to
something at run time, which QML needs. [1]

- What's the difference between ContactListModel and PersonSetModel?
I was expecting to see one model with:
 PersonA
    \- ContactA
    \- ContactB
 PersonB
    \- ContactC

What's the current design plan?

 - Have you considered using Collabora's way of doing tree models
(using a class called TreeNode)? see Tp-Yell. It's like your
abstractTreeItem except it also abstracts away from having to do all
this beginInsertRows stuff yourself, you simply append to the relevant
parent, or remove an object and it will sort itself out. It takes a
bit of getting used to. Useful for big tree lists.

- If you went down that route, if we're clever we can use Martin's
group model code directly with minimal changes to get it to work with
the person-set-model (but grouped by contact). Did you have any other
plans for this.

 - Only call something a ListModel if it's a list and not a tree, and
if something is a list inherit from QAbstractListModel.
 Currently:
   ContactsListModel is a tree.
   PersonSetModel is a list.

- What's the planned mechanism to get a Tp::Contact from a
KTelepathy::Contact? For performing write-operations in the contact
list, we need to be able to perform a tonne of actions on the contact
such as "block".

- Related: we also need a method to get an account for a contact for
tasks like createTextChannel(), this is currently achieved by a sneaky
hack in the accounts-model, this won't be available to us in the new
nepomuk models. The old KJob code appears to simply loop through all
the accounts (or TelepathyAccountProxies) looking for it. Though I may
have misread it.

[1] http://doc.qt.nokia.com/4.7-snapshot/qabstractitemmodel.html#setRoleNames