Thoughts and Questions on the Nepomuk Models

[George Goldberg]

On 18 June 2011 03:18, David Edmundson <david at davidedmundson.co.uk> wrote:
> 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.

Hi David,

I think you picked a bad moment to do this unfortunately. A lot of the
code in telepathy-kde is old redundant stuff. That includes the
ContactList Model. Look in the CMakeLists.txt file to see which files
are actually built - these are the currently interesting ones. Also
there is a major patch on reviewboard since a couple of days ago which
fixes many of the issues you have raised.

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

Already done in reviewboard.

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

Already done in reviewboard.

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

Only PersonSetModel matters. The rest is old irrelevant code. As
discussed at the sprint, we should only display Person objects in the
model (and not their child Contacts), however, there can be some
expanded view of the Person object to see Contact level detail
optionally, but this would be in the delegate rather than by having a
crappy Kopete style Tree View.

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

This stuff predates Tp-Yell by several years. Perhaps could be cool
though. I'm happy to investigate it for the future.

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

Let's see when we get to it :)

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

Deprecated

>   PersonSetModel is a list.

Correct

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

As yet, only the read only code is implemented. Getting the
Tp::Contact is not yet implemented. I have a plan (as outlined at the
last sprint if you can remember all the way back then), but it's a bit
out of scope for this, so will address it another day.

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

As above (also the jobs folder stuff isn't ideal. It will be cleaned
up at some point soon before it gets re-enabled in the build).


--
George