Proof of concept − KIO mail://

[Pierre]

On Monday, September 24, 2018 1:36:23 PM CEST Daniel Vrátil wrote:
> Hi Pierre,
> 
> nice job!
> 
> I don't know if it's something that regular users would regularly, but it's
> certainly a nice showcase of what you can do with Akonadi :)
> 
> As a minor improvement, you could connect to
> Akonadi::FetchJob::itemsRetrieved() signal to populate the entries
> incrementally instead of waiting for the entire job to finish - that should
> make it look "faster" when opening larger folders (or retrieve the Items
> from the EntityTreeModel as well, since you already have it there). You
> could also populate UDS_MODIFICATION_TIME from Item.modificationTime() to
> allow sorting the emails by date :)
> 
> Dan

Hi

Thank you for your comments.

I have indeed a lot of work to do, including UDS_MODIFICATION_TIME, maybe 
enforcing folder icons and so on, but I lack time right now to do it. It will 
come in later.
The biggest issue in this code is the way folder items are fetched, but I 
disagree with your diagnostic :)
I think the best improvement would be to have that kind of code working :


    void playWithFolder(Collection coll)
    {
        SearchQuery q;
        q.addTerm(EmailSearchTerm(EmailSearchTerm::MessageStatus, 
MessageFlags::HasAttachment, SearchTerm::CondEqual));
        Collection::List colls;
        colls.append(coll);
     
        ItemSearchJob *job = new ItemSearchJob(q);
        job->setSearchCollections(colls);
        QObject::connect(job, &KJob::result, [](KJob* job) { … });
        job->fetchScope().fetchFullPayload();
    }


This could generate a blazingly fast SQL query. But I have not managed to get 
it working, my ItemSearchJob always find no item, so I ended up looking 
through the whole collection manually, a perfect example of badness.
Do you know how to make this work ? This would come in very handy I think.


 Pierre

> On Sunday, 23 September 2018 19:29:21 CEST Pierre wrote:
> > Hi
> > 
> > A few weeks ago, I noticed I spent a lot of time juggling between KMail
> > and
> > the other applications, searching for attachments that I did not save
> > locally… or trying to attach a file to an email only to find out that I
> > did
> > not save it and it was only available as another attachment.
> > So I figured out that a mail:// KIO would be quite nice for these usecases
> > : from okular, I could open PDFs from sent or received emails, from KMail
> > I could attach a file from another email… After a few days of hacking,
> > here is a proof of concept :
> > 
> > https://cgit.kde.org/scratch/ducroquet/kiomail.git/
> > 
> > If you are brave enough to install and try it, don't forget when running
> > CMake :
> > cmake -DCMAKE_INSTALL_PREFIX=/usr -DKDE_INSTALL_USE_QT_SYS_PATHS=TRUE ..
> > 
> > And after make install, restart kdeinit5 (simply type the kdeinit5
> > command). You can then open «mail:/» in dolphin or whatever to browse
> > your email attachments.
> > 
> > If you think this has any possible interest for users, I would gladly help
> > evolve this from PoC to real code…
> > 
> >  Pierre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20180929/1b9b1ebd/attachment.sig>