[Kde-pim] Re: State of KReparentingProxymodel

[Stephen Kelly]

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.

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

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.

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

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

Can I ask what your use-case for this proxy is?

All the best,

Steve.

> 
> 
> Thanks for you help,
> 
> Chris
> 
>> 
>> > 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/
>> 
>> _______________________________________________
>> 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/
> _______________________________________________
> 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/


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