--===============1068290123877586463== Content-Type: multipart/alternative; boundary="===============8507763582677780586==" --===============8507763582677780586== MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127023/#review92404 ----------------------------------------------------------- Fix it, then Ship it! src/propertyinfo.cpp (line 421) I'm not too keen on indexing this unless there is a clear use case. It just increases the size of the index. During the Nepomuk days we used to index and collect way too much information with the hope that we would be find amazing creative uses for the data. It did not end well. - Vishesh Handa On Feb. 9, 2016, 9:09 p.m., Kai Uwe Broulik wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127023/ > ----------------------------------------------------------- > > (Updated Feb. 9, 2016, 9:09 p.m.) > > > Review request for KDE Frameworks, KDEPIM, Daniel Vrátil, Sebastian Kügler, and Vishesh Handa. > > > Repository: kfilemetadata > > > Description > ------- > > This adds support for the user.xdg.origin.email.subject, user.xdg.origin.email.sender, user.xdg.origin.email.message-id xattrs [1] to KFileMetadata. > > This can (should :P) be populated by KMail when you save an attachment. > > Not too happy about the "displayName" I chose. Also we'll need to figure out what to index and how we can relate this information and present it to the user in a meaningful way. But at least let's collect the information first and then we can think about ways to handle this. > > [1] https://wiki.freedesktop.org/www/CommonExtendedAttributes/ > > > Diffs > ----- > > src/properties.h 6ceaca5 > src/propertyinfo.cpp 4d1fac4 > src/usermetadata.h 9e10d2a > src/usermetadata.cpp 5485d0e > > Diff: https://git.reviewboard.kde.org/r/127023/diff/ > > > Testing > ------- > > Not really. Tests pass, though. > > > Thanks, > > Kai Uwe Broulik > > --===============8507763582677780586== MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127023/

Fix it, then Ship it!

src/propertyinfo.cpp (Diff revision 1)
		421	d->valueType = QVariant::String;

I'm not too keen on indexing this unless there is a clear use case. It just increases the size of the index.

During the Nepomuk days we used to index and collect way too much information with the hope that we would be find amazing creative uses for the data. It did not end well.

- Vishesh Handa

On February 9th, 2016, 9:09 p.m. UTC, Kai Uwe Broulik wrote:

Review request for KDE Frameworks, KDEPIM, Daniel Vrátil, Sebastian Kügler, and Vishesh Handa.

By Kai Uwe Broulik.

Updated Feb. 9, 2016, 9:09 p.m.

Repository: kfilemetadata

Description

This adds support for the user.xdg.origin.email.subject, user.xdg.origin.email.sender, user.xdg.origin.email.message-id xattrs [1] to KFileMetadata.

This can (should :P) be populated by KMail when you save an attachment.

Not too happy about the "displayName" I chose. Also we'll need to figure out what to index and how we can relate this information and present it to the user in a meaningful way. But at least let's collect the information first and then we can think about ways to handle this.

[1] https://wiki.freedesktop.org/www/CommonExtendedAttributes/

Testing

Not really. Tests pass, though.

Diffs

src/properties.h (6ceaca5)
src/propertyinfo.cpp (4d1fac4)
src/usermetadata.h (9e10d2a)
src/usermetadata.cpp (5485d0e)

--===============8507763582677780586==-- --===============1068290123877586463== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KS2RlLWZyYW1l d29ya3MtZGV2ZWwgbWFpbGluZyBsaXN0CktkZS1mcmFtZXdvcmtzLWRldmVsQGtkZS5vcmcKaHR0 cHM6Ly9tYWlsLmtkZS5vcmcvbWFpbG1hbi9saXN0aW5mby9rZGUtZnJhbWV3b3Jrcy1kZXZlbAo= --===============1068290123877586463==--