Create Task
Maniphest T14896

KIO access to item payload subelements (attachments etc)
Open, Needs TriagePublic
Actions

Description

It could be useful to have a KIO exposure of content in the Akonadi storage below the item granularity.

Use cases:

  • Viewing a set of pictures attached to an email with Gwenview as slideshow
  • Temporary file used to make attachment available is deleted once another email is viewed, too bad if the program is still starting for that attachment in the email before (think LibreOffice), it will no longer find the file passed as argument (in 2011, still valid?)
  • 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
  • temporary file bad for files viewed and desktop session-management (e.g. viewing a PDF attachment with Okular)
  • "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 (in 2011, still valid?)
  • showing in path the origin of a file to be in a certain akonadi backend/service, not /tmp

Current State
Akonadi::Item has the methods QUrl Akonadi::Item::url(Akonadi::Item::UrlType type) const and static Akonadi::Item Akonadi::Item::fromUrl(const QUrl &url). The url used there has the pattern "akonadi:?item=id(&type=mime/type)".

The KIO system expects each filesystem to reflect the hierarchy of folders and files therein by the path of the URL, using names and path separators. Without that no relative nagivation is possible, e.g. to sibling elements or containers.

Braindump
A generic akonadi: KIO slave would expose the technology, whereas type-specific akonadi KIO slaves with schemes matching the content type (email:, calendar:, etc.) might make more sense to human users seeing that in the UI.

To be extended...

History: