On Sat, Jun 18, 2011 at 10:33 AM, George Goldberg <[email protected]> wrote: > On 18 June 2011 03:18, David Edmundson <[email protected]> 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 > [email protected] > https://mail.kde.org/mailman/listinfo/kde-telepathy > _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
