Thoughts and Questions on the Nepomuk Models

[David Edmundson]

On Sat, Jun 18, 2011 at 10:33 AM, George Goldberg
<grundleborg at googlemail.com> wrote:
> 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.

I really did choose a bad time didn't I. Ah well.
>
>> - 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.
>
Yeah, I wasn't suggesting the GUI had to look like that, but for a CL
delegate to display information like we proposed it needs the
information in the format above.
>>
>> 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.
>

I can't remember that far back which is why I need a reminder. I'm not
asking for an implementation - I'm just trying to plan out mine and
everyone's future stuff, trying to work out how it will work.

The last I remember we had TelepathyBridge - to lookup one from the
other, however I know there was talk to get rid of that.


>>
>> - 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
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>