[Kde-pim] Q: virtual / unread email collections; flags; drop data

[Stephen Kelly]

Sebastian Kügler wrote:

> Hey PIMsters,
> 
> <summary>
> - How do I create virtual folders based on a SPARQL query?
> - How would a SPARQL query showing unread emails look like?
> - Which are the canonical flags to be used for read and important?
> - How is the drag+drop data in kmail's items structured?
> </summary>

Virtual folders are one of two or three elephants in the corner which we 
haven't fully dealt with yet I think.

akonadiconsole has a tab for search which uses

http://api.kde.org/4.x-
api/kdepimlibs/akonadi/classAkonadi_1_1ItemSearchJob.html

And I believe kmail uses

http://api.kde.org/4.x-
api/kdepimlibs/akonadi/classAkonadi_1_1SearchCreateJob.html

I haven't tried it, but I guess you could use the collection returned from 
that job as the root item in an ETM.

init()
{
  KConfig *cfg ...
 
  qint64 colId = cfg->readEntry("searchCollection", -1);

  if (colIs != -1) {
    Collection col(colId);
    initModel(col);
    return;
  } 
  SearchCreateJob *job = new SearchCreateJob(this);
  ...
  connect(job, SLOT(slotSearchJobDone);
}

void slotSearchJobDone(KJob *job)
{
  if (job->error())
  {
    kDebug() << job->errorString();
    return;
  }
  Collection col = job->createdCollection();
  initModel(col);
}

void initModel(const Collection &col)
{
  m_changeRecorder = new ChangeRecorder(this);

  m_changeRecorder->itemFetchScope()->fetchFullPayload(true);
  m_changeRecorder->setCollectionMonitored(searchCollection);

  m_etm = new EntityTreeModel(changeRecorder, this);
  m_etm->setCollectionFetchStrategy(EntityTreeModel::FetchNoCollections);
}

If it should be possible to show multiple search collections at once (for 
example if the DataEngine gives out data for multiple lion mail widgets) it 
would make sense to have them all in one etm. The way it should be would be 
for a search job to create a top level virtual resource instead of a virtual 
collection in the one search resource.

Then you would use m_changeRecorder-
>setResourceMonitored(searchResourceName) for each of the search resources 
created by searchcreatejobs, and the etm would have a top level collection 
for each of them, which could then be marshalled by the data engine or a 
KSelectionProxyModel.

There's a whole wiki page on this stuff, but it hasn't been high enough 
priority to implement the technical details yet.

http://techbase.kde.org/Projects/PIM/Akonadi/VirtualCollections

For the moment just use the setCollectionMonitored() with multiple etms if 
needed. 

I have no idea what a particular SPARQL query for unread emails would look 
like.

> 
> 
> I've done some Lion Mail hacking during the past days, and am now at a
> point where things start working again -- in principle -- through the use
> of the EntityTreeModel. That seems to work quite well, cool. :) (Code is
> in playground/base/applets/lionmail.)
> 
> Now I need to touch new ground. I can show a collection, get change
> notifications and all that, but it's still just a normal collection. What
> I'd like (need), is:
> 
> - a collection showing unread emails in the inbox (easiest case)

The easiest implementation would be to init the ETM with the inbox as the 
monitored collection. That will fetch all mails. Then a filter proxy to 
filter out anything that's not unread.

> - a collection showing unread emails from folder A, B, C (poweruser case)

Calling setCollectionMonitored multiple times and putting that into an etm 
won't work here anyway. Maybe I can look into implementing that. It might 
not be too hard. What you could do today though is to fetch the whole 
collection tree and use lazyitempopulation and a 
Akonadi::SelectionProxyModel with a CheckableItemsProxyModel. 

See the checkable items tab in the etm_usage example application which does 
something like that but with a KSelectionProxyModel. You could 
programmatically manipulate a QItemSelectionModel representing the checked 
items and save and restore the checked items to KConfig with 
akonadi_next/ETMViewStateSaver::setSelectionModel.

That again would give you a list of all emails, and you would need a filter 
to get the unread ones only.

> - a collection showing emails marked as important

Similar to unread.

Maybe I'll add a tab to the etm_usage app showing how to do this.

> 
> My guess would be that I need a suitable SPARQL query to setup the
> 'virtual collection', and a sortproxymodel to massage it into an ordered
> list I can work with. I know next to nothing about SPARQL (but some SQL),
> so if someone had an example I could modify, that would be most helpful.
> An example how I'd setup a virtual folder based on a SPARQL query would be
> very useful as well.
> 
> 
> Something else I'm rather confused about are flags. The ones I find in my
> Akonadi-collected emails are "\SEEN", "\Seen", "important", "\FLAGGED".
> Which ones are the right ones to use? Or should I go hunt for Nepomuk tags
> of emails?

See messagestore/messagestatus.h ::setStatusFromFlags. Don't try to read or 
manipulate them yourself.

> 
> 
> Then, drag & drop. What I'm doing right now is put a URL list into the
> drop data, but that doesn't seem to be accepted as valid drop data by
> KMail. What's the right way to go about this? I can sift through the kmail
> code base, but if anyone here knows off-hand, that would save me some time
> I'd rather spend at the swimming pool. :-)

The ETM should handle the drops of a KUrl::List of Akonadi Urls. If it 
doesn't I guess I'll look into it :)

All the best,

Steve.

> 
> Thanks for the hints (so far, and the coming up ones :)).
> 
> Cheers,


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