<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/109538/">http://git.reviewboard.kde.org/r/109538/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On March 17th, 2013, 2:05 p.m. UTC, <b>Vishesh Handa</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">But why? KFileMetadataReader and the other KFileMetadataStuff should just be marked as deprecated. Why are we porting them? We already have better alternatives in the nepomuk-widgets repository.</pre>
</blockquote>
<p>On March 17th, 2013, 2:12 p.m. UTC, <b>Martin Tobias Holmedahl Sandsmark</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Because it was a simple user of KProcess.
But if we can just deprecate the whole class (and move it into kde4support, I guess?) that's better. :-)</pre>
</blockquote>
<p>On March 17th, 2013, 4:08 p.m. UTC, <b>Vishesh Handa</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">As far as I'm concerned it can be deprecated. We can definitely deprecate KFileMetadataWidget which is the only user of this KFileMetadataReader. Dolphin now uses Nepomuk2::FileMetadataWidget. The only slight problem might be that Dolphin still likes being "Nepomuk Optional" at compile time. So they still use it. Maybe we should talk to Frank about this?
The only other class is KFileMetaInfo, which uses Strigi directly. I still have to write a replacement for that in Nepomuk.
@David: I think we talked about this in Berlin. Should we deprecate KFileMetadataWidget?</pre>
</blockquote>
<p>On March 18th, 2013, 6:56 a.m. UTC, <b>Kevin Ottens</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Yep, that's what we discussed in Berlin, this one could move to kde4support indeed.</pre>
</blockquote>
<p>On March 18th, 2013, 11:40 a.m. UTC, <b>Frank Reininghaus</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I think we'll keep the "Nepomuk optional for building Dolphin" thing in KDE 4.x. Accoding to feedback I got from users, some people like to build Dolphin with as few dependencies as possible. But for Frameworks, I don't really see a point in it. We'll depend on many different frameworks anyway, so replacing the parts of kdelibs that are needed for KFileMetaDataWidget by nepomuk-core and nepomuk-widgets has hard, non-optional dependencies looks reasonable to me.
But then I wonder why we should even bother to keep KFileMetaDataWidget at all? Shipping code that is unmaintained, even if it is "just" in kde4support, does not look like a good idea to me. Couldn't it just be removed? Porting to Nepomuk's widget is simple enough, and if people feel that this makes porting apps to Frameworks too hard, one could still put a simple header file into kde4support that makes KFileMetaDataWidget a typedef for Nepomuk's widget.</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">We keep them around to make it easier for people to port. It's better than breaking everyone builds in one go for a gazillion of dependencies. kde4support is really a porting tool.</pre>
<br />
<p>- Kevin</p>
<br />
<p>On March 17th, 2013, 1:26 p.m. UTC, Martin Tobias Holmedahl Sandsmark wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for KDE Frameworks, kdelibs, David Faure, and Vishesh Handa.</div>
<div>By Martin Tobias Holmedahl Sandsmark.</div>
<p style="color: grey;"><i>Updated March 17, 2013, 1:26 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">KFileMetaDataReader currently uses KProcess, this ports it to use QProcess instead.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">it builds.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kio/kfile/kfilemetadatareader.cpp <span style="color: grey">(88cadaa)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/109538/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>