[Kde-pim] kio-slave for (email) attachments and other file-like items stored in Akonadi
Friedrich W. H. Kossebau
kossebau at kde.org
Thu Apr 28 22:30:45 BST 2011
Hi,
doesn't this annoy you as well? You boot your KDE session and Okular greets
you with that it cannot reopen the PDF file you have been sent the other day
and have started to work on, and once you found the email with the PDF again
and opened it, you see that all the bookmarks/comments you created in some
hours are lost because Okular cannot map the (random) url to the very same
document. Bah.
At least the Okular greeting happened to me yesterday again, and so I
remembered what I proposed to Tobias König (Hei :) ) at the begin of this year
and just added it in time to the soft feature freeze to the 4.7 feature plan,
because I want to get it done finally:
a kio-slave to access email attachments and other file-like items stored in
Akonadi.
Current situation (not sure this holds with KMail2, please correct me):
Attachments in KMail (and else? where?) which are to be shown/opened with
another program are written to a file in the real filesystem, somewhere in
/tmp, with the "real" filename as given for the attachment + some random
string + mimetype file extension.
But:
* File is deleted once another email is viewed, too bad if the program is
still starting for that attachment in the email before (think OOo), it will no
longer find the file passed as argument
* path/name of the file is different each time, bad for programs which store
own data per file by the full path of that file (e.g. Okular)
* temporary file also bad with regard to "Recently opened" list and session-
management (example given above)
* "Save as" on attachment opened in external program does not have the
original file name as default in the file dialog, instead that filled with
that random (crap) chars which always have to be manually removed first to get
a sane name.
I guess this could be solved with a kio-slave which can deliver the real data
of an attachment by a constant unique identifying url from Akonadi.
Tobias told me to have a look at the akonadi:/ kio-slave which I did and also
started with some code those days (but lost it meanwhile). IIRC I stopped
because I was not sure if such a feature should be added to the existing
akonadi kio-slave or to a separate one. I also was wondering about all the
copying going on and if that could not be done more efficiently (like in a
best case getting an offset to a file from which the kio-slave would do the
reading and, if needed, decoding, e.g. from base64, and then stream that to
whatever is ).
What do you think? Anything like this meanwhile started by someone else? How
would you do it? Who wants to cooperate on this? Where would I put the code?
And else?
Cheers
Friedrich
--
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
_______________________________________________
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/
More information about the kde-pim
mailing list