<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/127655/">https://git.reviewboard.kde.org/r/127655/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On April 29th, 2016, 3:15 a.m. UTC, <b>Michael Pyne</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 I disagree with the idea of overwriting KAboutData properties if they are already set by the user. Alex, any thoughts?
In the event the KAboutData doesn't already exist I think automatically setting it up makes sense, and QCoreApplication is a good source. But I would rather flag property conflicts than to break ties when developer selects two different values for same property, as that's change in behavior might break other parts of code that rely on KAboutData not changing values.
Would this partial solution be OK for the problem you're running into?</pre>
</blockquote>
<p>On April 29th, 2016, 11:09 p.m. UTC, <b>Albert Astals Cid</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;"><blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I think I disagree with the idea of overwriting KAboutData properties if they are already set by the user. Alex, any thoughts?</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I agree with Michael, it seems strage it overwriting what you may have set in setAboutData.</p></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;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Hm. Would it not be more strange if one cannot be sure that KAboutData::applicationData().displayName() matches app->applicationDisplayName()? And similar for the other shared/mapped application metadata properties? Why would I rather expect the original property of the KAboutData value to be kept, than it being updated to its counterpart in the Q*Application metadata, if changed by the Qt-API afterwards?
Surprised to see you expecting things to be different :)</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Not that I expect it to happen a lot in real world code that the metadata of applications is set/reset by independent code snippets (and thus a mixture of KAboutData-using and Q*Application::setX-using), where random orders of writing and reading the data can happen. But if it happens, should not both Q*Application::setX and KAboutData::setApplicationData be equi-mighty, and both be acting on the same effective properties when it comes to metadata about the application instance, where it makes sense and is defined as such?</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Or, why should KAboutData::setApplicationData be allowed to overrule any already set QApplication metadata (which makes sense to everyone), but not the other way around? :) Why should KAboutData::setApplicationData be write-through, but KAboutData::applicationData not be read-through?</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Like it is now, if I would want to use metadata of the application, I cannot rely on KAboutData::applicationData alone, I also have to separately read things by Q*Application::x, to be sure to really have the values also used by other Qt-only parts of the code. Which renders the duplicates of those Q*Application properties in KAboutData useless, no?
I would expect more code to be broken if it relies only on KAboutData::applicationData() than code which expects any properties to keep their values, even if getting out-of-sync with the Qt application metadata.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">For the bug which motivated me to write this patch, agreeing on initialising at least the global KAboutData instance to current Q*Application data should be fine, so will change the patch to that now. But well, I think this initial patch should be the way to go and yield less surprising behaviour :)</p></pre>
<br />
<p>- Friedrich W. H.</p>
<br />
<p>On April 28th, 2016, 1:04 a.m. UTC, Friedrich W. H. Kossebau wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: 1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
<div>Review request for KDE Frameworks, Alex Richardson and Michael Pyne.</div>
<div>By Friedrich W. H. Kossebau.</div>
<p style="color: grey;"><i>Updated April 28, 2016, 1:04 a.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kcoreaddons
</div>
<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;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">KAboutData is passed as values on getting and setting the "applicationData",
and it only makes sense to have its properties be a transparent access
to the actual mirrored Q*Application metadata.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Even more as there is code in KF5 (e.g. KXMLGUI) which relies on KAboutData::applicationData(),
without requiring the user to use KAboutData::setApplicationData().</p></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;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Added autotests pass.</p></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>autotests/kaboutdatatest.cpp <span style="color: grey">(f31e7f3)</span></li>
<li>src/lib/kaboutdata.h <span style="color: grey">(97c0f2b)</span></li>
<li>src/lib/kaboutdata.cpp <span style="color: grey">(ceb0c06)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/127655/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>