[Kde-pim] Baloo based Qml API for (Active) Mail + Plasma

[Christian Mollekopf]

On Thursday 23 January 2014 15.05:02 Michael Bohlender wrote:
> Thanks for your input!
> 
> Baloo does not store the data I want, so a mostly baloo based API is not an
> option.
> This also means that there is no point in modifying the baloo pim search to
> retrieve the title because we either need it all or just the id.
> 

Agreed.

> Looks like the predefined-search-folder-feature is also interesting for the
> desktop client. Implementing it on the akonadi server side is an obvious
> choice then. I am a little worried, that I might lose some control over the
> message list that way. E.g. I don't want the mails to instantly disappear
> from an "unread" list, just because I opened them (and marked them as read
> that way). I want them stay there till I close that listview.  Anyway. I
> think I can work around this  (if there is not already a solution) and
> potential other problems in the QML API.

Well, we'll need a solution for this as well on the desktop, so if you can 
come up with ideas how it is supposed to work I'm sure we'll arrive at 
something that works for all of us.

We have to consider what state information belongs to the client, and what 
information is shared by all clients (and can thus be moved to the akonadi 
server). In other words, things should behave as expected when having multiple 
clients open working on the same folders.
I suppose for the mark-as-read case it makes sense that if the mail disappears 
from one client it also disappears from all other clients (that use the same 
meta-folder).

> 
> So much about just exposing some baloo features to qml and doing  the rest
> client side... :)

;-)

> I have never looked at the  source code and don't know where to start. Any
> Pointers?
> 

We're currently beating the search infrastructure into shape so we can unleash 
the power of baloo.
I think what you currently could do best is come up with concepts how stuff is 
supposed to behave (especially if we consider multiple clients working on the 
same virtual-collections). That will give us some more usecases to make sure 
we don't miss anything essential.

Or of course the model stack, that you base on an ETM.
I suppose we'd want something like a metafolder model displaying all 
metafolders for a given mimetype. In the actual filelist you then just display 
the content of that folder, so that's already existing.

For your QML components you'd probably just have to expose the relevant parts 
of the models so you can use them there, right?

Cheers,
Christian

> Cheers,
> 
> Mike
> _______________________________________________
> 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/