<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/127896/">https://git.reviewboard.kde.org/r/127896/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On May 12th, 2016, 6:15 a.m. UTC, <b>Kåre Särs</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 this patch should not include any platform specific defines. Disabling DBus requirement on Windows might also be interesting for some projects. I propose to do something similar to what is done in kxmlgui to disable kglobalaccel. The default is to require kglobalaccel, but if you knowingly specify "-DFORCE_DISABLE_KGLOBALACCEL=1" kglobalaccel is not required or searched for.</pre>
</blockquote>
<p>On May 12th, 2016, 8:05 a.m. UTC, <b>René J.V. Bertin</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;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">True, even if there's probably very little point in disabling DBus on a standard Unix/Linux set-up.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">But indeed, a platform-agnostic option can still be included in the options that will be flipped by a platform-specific option like <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">APPLE_STANDALONE_BUNDLE</code> I've proposed in a patch for Marble.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">To come back to what I suggested earlier: even if there were to be a KF5 framework that encapsulates DBus or "something more platform native" there would still be a use-case for using DBus through that framework even on OS X (or MS Windows). Projects like HomeBrew, MacPorts and Cygwin don't exist to replace the native desktop, but to complement it; to provide an easy way to install and maintain FOSS and provide a context in which those applications can run as much as possible as they do on their native platform. That evidently includes DBus, but not just so that Gnome apps can talk with other Gnome apps and KDE apps with other KDE apps. I don't have any stats on this, but I'd expect that a good many of the users of such projects use them not so much for software development per se, but as tools for their actual work (often in science and/or engineering, in my impression). That might very well include using Gnome/GTk apps alongside KDE applications, and in that case they'd probably expect the same kind of interoperability as those apps would have on the other platforms they might use.
IOW, I don't think a distribution system that aims to provide the best possible context for the applications it carries can get around using DBus.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">But this is probably not the best place for an in-depth discussion around underlying principles; that should probably be done on a ML (and ideally include a DBus dev or two).</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;">i don't see a reason behind introducing a special cmake option other than code coverage (test dbus and dbus-free branches with the same qt): why one should want to disable dbus on a system where he/she has Qt with dbus?</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">can you explain this to me?</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">regarding homebrew, i repeat: by default it installs a precompiled version of Qt without dbus. if user wants dbus then he/she has to have homebrew recompile whole Qt (takes about 1 hour). and what if kde app doesn't need any IPC? that would just pollute his/her system with redundant stuff. how many gtk-based apps require dbus to run on windows and osx?</p></pre>
<br />
<p>- Nick</p>
<br />
<p>On May 12th, 2016, 5:16 a.m. UTC, Nick Shaforostoff 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 Software on Mac OS X, KDE Frameworks, David Edmundson, and Martin Gräßlin.</div>
<div>By Nick Shaforostoff.</div>
<p style="color: grey;"><i>Updated May 12, 2016, 5:16 a.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kauth
</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;">this is the first patch to make kde frameworks build (and then work) without dbus.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">this will allow homebrew users use precompiled vanilla Qt to build kde apps on osx. as dbus is not a common service in osx world, kde apps on osx should use native means for interprocess communication instead -- this will make them better citizens in osx ecosystem.</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;">compiles fine on osx, compiles fine on linux, tests on linux still 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>CMakeLists.txt <span style="color: grey">(48dc2d9)</span></li>
<li>autotests/BackendsManager.cpp <span style="color: grey">(59675b3)</span></li>
<li>autotests/CMakeLists.txt <span style="color: grey">(b53d760)</span></li>
<li>autotests/HelperTest.cpp <span style="color: grey">(8050a06)</span></li>
<li>src/CMakeLists.txt <span style="color: grey">(1b6930d)</span></li>
<li>src/ConfigureChecks.cmake <span style="color: grey">(d46761a)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/127896/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>