[Kde-pim] Re: State of KReparentingProxymodel

Sun Dec 5 00:13:36 GMT 2010

On Saturday 04 December 2010 19:36:47 Stephen Kelly wrote:
> Christian Mollekopf wrote:
> > On Wednesday 10 November 2010 14:04:45 Stephen Kelly wrote:
> >> Christian Mollekopf wrote:
> >> > Hi,
> >> > 
> >> > I need to create a treemodel based on the hierarchy of kcalendar
> >> > todos, in the same model i have also other items (notes), which
> >> > should be left flat.
> >> > 
> >> > I found KReparentingProxymodel to be exactly what i need, but i wonder
> >> > in what state this class is considered. It is not working for me (even
> >> > the simplest case, to not build any hierarchy with a flat
> >> > kdescendantsproxymodel as input), but i havent been looking into it
> >> > yet.
> >> > 
> >> > I copied the class from kdelibs/kdeui/tests/proxymodeltestapp/ as it
> >> > seems to be newer than the one in akonadi_next.
> >> > 
> >> > If you tell me that this is the latest version, i will start looking
> >> > into it.
> >> 
> >> Hi Chris,
> >> 
> >> The current state of that class is 'highly experimental'. It can be used
> >> for demos, but I know it has some bugs that I'm not certain how should
> >> be solved (mostly around new intermediate nodes arriving), but I
> >> haven't had time to work on it in a long time.
> >> 
> >> It looks like the version in proxymodeltestapp is slightly more up to
> >> date, but I also noticed a difference wrt mapToSource in the
> >> akonadi_next version which should maybe be in the class.
> >> 
> >> It is surprising that it doesn't work for you in even the simplest case.
> >> Did you try running the proxymodeltestapp and trying the 'reparenting
> >> PM' tab? That works for me.
> >> 
> >> All the best,
> >> 
> >> Steve.
> > 
> > Hi Steve,
> > 
> > Sorry for the late reply, I just found your mail, I missed it on the ML
> > =/
> > 
> > I got it working basically, although not all items are correctly mapped.
> > 
> > I think the cause for the incorrectly mapped items is in
> > KReparentingProxyModel::recreateMappings().
> > The qLowerBound algorithm works only as long, as the items in the model
> > are already in the correct order according to the targeted tree
> > structure.
> > 
> > Since we have several items which are on the same level (of tree
> > nesting), it is possible that the right parent node is missed and only a
> > remote parent node is found.
> > 
> > Testcase, specified parents, proxmodeltestapp:
> > [1, 2],
> > [1, 2,3],
> > [1, 2, 4],
> > [1, 5],
> > [1, 2, 6],
> > 
> > which should add 6 in tree below 2 (just after 4),
> > but instead adds it to 1 (after 5).
> 
> Thanks for investigating, and for the testcase. I'll keep that in mind when
> I review this class again. I don't have time to try out your testcase this
> evening.

No hurry =)

> 
> > The second problem is that all slots are in the private class:
> > 
> > In my subclass i need to build a tree of all items, so i can tell if an
> > item is a remote descendant of the given ancestor (otherwise i would have
> > go trough
> > all sourcemodel items in  each call of isDescendantOf).
> > 
> > I.e. if the model is reset, i need to rebuild the tree in my subclass
> > before endResetProxy rebuilds the internal map. Same for new items which
> > are added etc.
> 
> For resetting, Qt 4.8 will have a pseudo-virtual slot which you can
> implement for when the proxy is reset:
> 
> void resetInternalData();
> 
> http://qt.gitorious.org/qt/qt/merge_requests/694
>

ok, that will solve the issue for resetting models.

> For Qt earlier than 4.8 the workaround is connecting your own slot at the
> correct point of a setSourceModel reimplementation. See the unit test in
> the MR for more details.

yes, thats what i'm doing now.

> 
> > Therfore i propose to make all those private slots protected virtual
> > slots.
> 
> I think this should be avoided because it exposes too much API which really
> should be internal.
> 
> I do see though why you need to update your mappings when source items are
> inserted, moved or removed. We can probably add API specifically for that
> purpose.
> 
That makes sense, i will propose something.

> > I'll provide a patch for both issues, but i don't know on which version
> > of kreparentingproxymodel i should work. Atm. I work on the version in
> > kdelibs/kdeui/tests/proxymodeltestapp so i can check the test, but as it
> > is not installed, i build it directly in my app where i use it...
> > 
> > The version in akonadi_next would be installed, but then i can not test
> > it with proxymodeltestapp, so I'm not sure what to do...
> 
> One option would be to locally link your proxymodeltestapp to akonadi_next.
> As long as akonadi_next is already installed, that should work (although
> akonadi_next doesn't install any headers, so you'd probably have to hack
> that too).

So should that be done locally or in the repository? I assume that finally the 
reparentingproxy should end up in kdelibs/kdeui as the identityproxy?

If i start working in akonadi_next, can i replace the version in akonadi_next 
with the one from kdeui?

> 
> Can I ask what your use-case for this proxy is?
> 
I'm working on an app for storing everything i need to remember (notes, todos, 
events). For this i use akonadi as backend (with the Calendar and the new 
Notes Resources). For organizing the items and adding additional content i use 
nepomuk topics.

So i use the reparenting proxy for showing a treemodel of the topics (with 
subtopics), and for showing the sub-todos below their parent todo in the 
itemlist (as input i have a flat list with notes, todos and events mixed).

Cheers,

Chris

_______________________________________________
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/