<table><tr><td style="">astippich added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D25517">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D25517#587776" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D25517#587776</a>, <a href="https://phabricator.kde.org/p/bruns/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@bruns</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>I have thought about this and have come to the conclusion this is not really future proof.</p>

<p>The <tt style="background: #ebebeb; font-size: 13px;">Property::FrontCover</tt> is IMHO fine, i.e. the changes to <tt style="background: #ebebeb; font-size: 13px;">propertyinfo.cpp</tt> and <tt style="background: #ebebeb; font-size: 13px;">properties.h</tt> could go in as is.</p>

<p>The request of additional properties should be done differently. How about the following:</p>

<ol class="remarkup-list">
<li class="remarkup-list-item">divide properties into (currently) two sets, "Simple Metadata" (all the current ones but frontcover) and "Complex Metadata" (currently frontcover).</li>
<li class="remarkup-list-item">allow to specify extra properties for SimpleExtractionResult</li>
</ol></div>
</blockquote>

<p>Not strictly against your proposal, but how much do we gain? What is your concern about future proof?<br />
From my Elisa application perspective, it would be very convenient to use the proposed ExtractionResult::ExtractEverythingIncludingImageData (or renamed ExtractionResult::ExtractEverything for KF6) and the ExtractionResult::ExtractImageData flags.<br />
For the current proposal the API does not need to be changed.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">SimpleExtractionResult result(fileName, mimeType);
result.setExtraProperties({Property::FrontCover});
plugin.extract(&result);</pre></div>

<p>You can then also do:</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">SimpleExtractionResult result(fileName, mimeType, ExtractionResult::ExtractNothing);
result.setExtraProperties({Property::FrontCover, Property::BandLogo});
plugin.extract(&result);</pre></div></blockquote>

<p>This is also possible with the current proposal (when the extractors honor the ExtractionResult::ExtractNothing/ExtractMetaData flags properly, which I think currently none does) by just setting the ExtractionResult::ExtractImageData.<br />
It is just that one does not have fine-grained control over each individual "complex" property, but IMHO we do not need that.<br />
I also fear that it may not be clear to distinguish between "simple" and "complex" properties and that users of the API would expect that every property works for the setExtraProperties, which would require an immense amount of work for all extractors.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R286 KFileMetaData</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D25517">https://phabricator.kde.org/D25517</a></div></div><br /><div><strong>To: </strong>astippich, Baloo, bruns, mgallien, ngraham<br /><strong>Cc: </strong>kde-frameworks-devel, hurikhan77, lots0logs, LeGast00n, fbampaloukas, GB_2, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, bruns, abrahams<br /></div>