[Kde-pim] Propossal: Akonadi::Model::ItemCreateJob

[Eduardo Robles Elvira]

Hello everyone (and Stephen who wrote EntityTreeModel)!

I'm developing the konqueror bookmarks resource for gsoc using Akonadi
and Nepomuk as some you already know. For the Bookmarks Organizer I
will be using / extending some model/views provided by Akonadi. For
displaying the bookmarks I will use EntityTreeModel from akonadi_next.

One thing I want to be able to do is adding a new bookmark item to the
model and selecting it immediately so that the user can edit it.
That's currently not doable with Akonadi models because they're async,
so currently if I do a ItemCreateJob for adding my new Item, I need to
wait until the Monitor signals itemAdded() for that item, so that the
model catches that signal and adds the new item to its internal
representation. And there's no guarantee that no other monitor signals
are received before that happens, so one never knows in advance which
will be the QModelIndex for the added item.

For solving that problem, I propose creating
Akonadi::Model::ItemCreateJob, which I could use this way:

    using Akonadi;
    ...
    Item item;
    QModelIndex parent = QModelIndex(); // parent model index which
refers to the root collection in my case
    Model::ItemCreateJob* itemCreateJob = new
myEntityTreeModel->itemCreateJob(item, parent );
    if(job->exec())
    {
        myEntityTreeView->setCurrentIndex(itemCreateJob->itemIndex());
    } else
    {
        kWarning() << "Item Create Job error: " <<
itemCreateJob->errorString() << endl;
    }

I could also do the same asynchronously also with:

    connect( itemCreateJob, SIGNAL( result( KJob* ) ), SLOT(
itemCreateJobDone( KJob* ) ) );

Internally EntityTreeModel::ItemCreateJob will wrap around
Akonadi::ItemCreateJob. After Akonadi::ItemCreateJob executes, if it's
successful, EntityTreeModel will temporally cache the item that have
been just added to Akonadi, and without waiting for the itemAdded()
signal from the monitor it will add it to the EntityTreeModel internal
database as if itemAdded() had already been called.

When the monitor sends the itemAdded() for the recently added item,
the EntityTreeModel would find that the added item is already in its
database, unmark it as "cached", and ignore the signal because the
item is already in its internal database. And this should always work
because the Akonadi::ItemCreateJob executed successfully, so if
Akonadi behaves correctly, we know that sooner or later we will get
the item from monitor, as it has already been added to Akonadi.

In Konqueror bookmarks I would need to do exactly the same for adding
bookmark folders (which are collections), so if you like the approach
described here I will develop the Model::ItemCreateJob  and also
Model::CollectionCreateJob.

Some open issues:
  * This requires a patch for each Akonadi Model in which it's
implemented (EntityTreeModel, CollectionModel, ItemModel).
  * That's why I've thought about creating an Abstract parent class
called Model::ItemCreateJob (Model::AbstractItemCreateJob seems too
large?). Also as this class has the same name as an already existing
job not related to model/view programming, that's why I suggest
creating its own namespace (Akonadi::Model::ItemCreateJob), but if
you've got a better idea for the naming of these classes I'm
listening.

Regards,
     Eduardo Robles Elvira.
_______________________________________________
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/