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-...@kde.org > https://mail.kde.org/mailman/listinfo/kde-pim > KDE PIM home page at http://pim.kde.org/ _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
