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

[Sebastian Kügler]

Hey,

On Tuesday 20 July 2010 22:57:44 Stephen Kelly wrote:
> Sebastian
Kügler wrote:
> > <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()
> {
[...]
> }
> 
> 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.

For now, I've directly implemented
the collection fetching in the Lion Mail Plasmoid, so that it basically
boils down to a creating, removing and updating widgets on the ETM's
corresponding signals, and some chrome and administration around it,
filtering is done by hand by accepting or discarding the individual
Akonadi::Items I get from the ETM. 

Works pretty OK I must say: During last
night's hacking session I got my first Akonadi-based new EmailWidget popping
up in Lion Mail, so basically the chain works from end to end, including
PUSH IMAP. Pretty cool, I press send on one machine and within 5 seconds the
new email shows up in Lion Mail.

The configuration is hardcoded right now
rgd the collection ID, but I've got pretty good hints where to start with
this, just didn't get around to it yet.

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

That would work I guess. I've gone the "easy, works now" route for
now, with the "nice clean implementation" route in the background, for a
first version I think it's good enough. Once the whole virtual folder thing
is worked out, it should be easy enough to switch to that, and extend Lion
Mail feature wise.

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

Ah, haven't even used a proxy model
for that, next up :-) (I'm learning more MVC as we go, so that's cool.)

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

I'm a bit
unsure what LazyPopulation actually does. It won't fetch the data
immediately, but does it only care about updated items then? Or it is a
model which is populated "somewhen", so there's absolutely no guarantee what
shows up and when?

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

Sounds easy enough, give that it's just another flag.

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

Alright, I'm using that one now. I've copied it
into the Lion Mail sources for now, we might want to consider adding this to
pimlibs, it's self-contained and small enough for that, it seems.

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

Basically, drop data can be either mime data (the email payload
for example) or a list of URLs. The dropdata Lion Mail sets when a drag is
started is simply a (one element) list of Akonadi URLs. Shouldn't be hard to
get right, just needs a bit of coordination. (Which is what we're doing
right now. :))

Cheers, and thanks for the help. I'm still digesting most of
it, but the pointers are already very helpful (also thanks Thomas and
Kevin!).
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID:
9119 0EF9
_______________________________________________
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/