[Kde-pim] models TODO list

[Stephen Kelly]

Hi,

I've not had the time for akonadi stuff for a few weeks, and that's going to 
continue for about a week or two. Here's some things that need to be done in 
the models area if anyone else wants to pick any of them up. It would be 
nice to increase the bus factor a bit. I can provide help on IRC if needed.

[*] Crashes and broken-ness.
There's a crash when synchronizing KAddressBook that I haven't had time to 
look into yet. (I can't find the bug report for it right now)
Tokoe also reported that merging didn't work for him when choosing the email 
address to use when adding to a group. I couldn't reproduce yet , but it 
doesn't look like there's any code in ETM  causing it, so it's an obscure 
bug.

[*] Unit tests. 
The EntityTreeModel unit test suite is 'almost there'. It's tricky because 
the 
fakeserver writes session events on its socket, but doesn't know when the 
job 
attached to the Akonadi::Session has fully processed the chunk of data sent. 
This can probably be solved by adding a signal to FakeSession which the test 
suite can react to by emitting the next partial job result or monitor event. 
Additionally, the KSelectionProxyModel test suite became more versatile 
recently by allowing to change the selection during the test, but I haven't 
had a chance to write tests making use of it yet.

[*] Monitor/List job race conditions .

Here's a scenario:

1. Start list job
2. Monitor notifies that one of the items in the collection we're fetching 
has 
been removed. ETM removes the item.
3. Job results come in including the item we've just removed, we add the 
received item, and then we have an item in the model which does not exist in 
Akonadi. This is a time-bomb.

Monitor could get API to change it to this:

0. Pause Monitor.
1. Start list job
2. Monitor notified over DBus that the item has been removed. Monitor 
doesn't 
notify the model because it is paused. Instead Monitor caches the 
notification.
3. process list results as the come in
4. The list job ends. Unpause the monitor, and remove the item it notifies 
about.

This might still be a problem because the removed item will be in the model 
between when it is added from the list job, and when it is removed by the 
monitor signal. In a really big listing, the user might have enough time to 
interact with the item. An alternative might be to cache the monitor 
notifications in the ETM while running list jobs, and check to see if new 
objects from lists have been notified as removed since we started the list 
job. 
I haven't given it enough thought yet though.

Volker mentioned that ChangeRecorder has the functionality needed, so ETM 
likely just has to be changed to take that instead of a Monitor in its ctor 
and use that API.


[*] Merge KDescendantsProxyModel with KReparentingProxyModel

Currently KDescendantsProxyModel is broken. It uses as its index internalId 
the internalId of the index in the source model. This means that if 
internalIds are not unique in the first column of the source model, 
everything 
breaks. That's fine for ETM, because internalIds are unique there, but if a 
QSortFilterProxyModel is used in between, the internalIds are not unique for 
an index. The reason is I wrote it a long time ago and didn't know what I 
was 
doing  :). This caused trouble for dfaure on Friday with KAddressBook. The 
solution was to remove the EntityFilterProxyModel(is-a 
QSortFilterProxyModel) 
because it wasn't needed anyway, but it still needs to be fixed.

KReparentingProxyModel handles this correctly with a real mapping of 
QPersistentModelIndexes, but it also requires some stuff from 
KDescendantsProxyModel, such as delayed insertion of children of new rows. 
It 
would make sense to merge these two proxies because it's less code to 
maintain, and KDescendantsProxyModel becomes a trivial subclass of 
KReparentingProxyModel with an implementation like 

KDescendantsProxyModel::isDescendantOf(const QModelIndex &ancestor,  const 
QModelIndex &descendant)
{
        return !ancestor.isValid() && descendant.isValid();
}

I haven't fully thought that through yet, but the implementation would 
certainly be trivial whatever it is. Finishing KReparentingProxyModel 
shouldn't be a really big deal. It has most useful utility methods already. 
It's just a case of handing the removed signals, and the data changed 
signals.

[*] Amazing Completion

Need to get the kdevelop code which does completion in a popup display for 
navigating to classes etc, merge the effort with amazing completion and 
create 
an extensible set of K-Classes for doing that stuff. Most likely the most 
useful part of the kdevelop stuff is the popup stuff. Then the MailModel 
needs 
to handle Amazingcompletion, which is easy, and it needs to get a delegate 
which can show all the information for the item (eg, [first name, last name, 
email] for contacts). My effort so far has been slowed by knowing very 
little 
about painting. The popup needs to be designed in such a way as to be 
extensible with extra actions such as 'include the results of a remote 
search 
on that LDAP server in the results list. This is then related to virtual 
collections.

[*] Virtual collections
Some behaviour of the model wrt virtual collections is still unresolved. 
http://thread.gmane.org/gmane.comp.kde.devel.pim/25372

I need to find the time and scenarios to convince Volker that virtual 
collections should be omitted by default anyway :).


[*] Support move signals in proxies and implement move support in ETM.

I think ETM already has some code for handling moves which doesn't get used 
yet. Now that akonadi can signal moves it should be completed, and supported 
in the proxies. The proxies also need to handle the 
layout{,AboutToBe}Changed 
signals, which probably they don't yet. Hopefully it's just two proxies: 
KReparenting and KSelectionProxyModel, though the implementation of both 
should be trivial. QSortFilterProxyModel doesn't react to the move signals 
yet, but the only result that shouldn't really have bad results as handling 
the new move signals in proxies is only an optimization which can come 
anytime. Otherwise handling the layout changed stuff properly is enough.

[*] Fix the handling of collection list job
Currently if a Collection from a list job can't be inserted into the ETM 
tree 
because its parent isn't there yet, the Collection is cached as pending 
until 
its parent is in the model. The code is ugly and should be changed to insert 
empty nodes in the tree instead using the parentCollection() as was recently 
fixed in the handling of CollectionAdded signals.

That's pretty much everything I can think of right now. 


All the best,

Steve.


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