[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: Review Request 127896: make dbus optional on osx: kauth
From: René J.V. Bertin <rjvbertin () gmail ! com>
Date: 2016-05-12 12:41:48
Message-ID: 20160512124148.20214.61320 () mimi ! kde ! org
[Download RAW message or body]
--===============8835416500297821023==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> On May 12, 2016, 8:15 a.m., Kåre Särs wrote:
> > 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.
>
> René J.V. Bertin wrote:
> True, even if there's probably very little point in disabling DBus on a standard \
> Unix/Linux set-up.
> But indeed, a platform-agnostic option can still be included in the options that \
> will be flipped by a platform-specific option like `APPLE_STANDALONE_BUNDLE` I've \
> proposed in a patch for Marble.
> 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 proba
bly 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.
> 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).
> Nick Shaforostoff wrote:
> 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?
> can you explain this to me?
>
> 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?
> Kåre Särs wrote:
> We have Kate as an example. At the moment the main thing we need DBus for on \
> windows is opening documents in only one window when opening new documents through \
> explorer. Without the DBus daemon it does not work. KDevelop has a solution for it \
> without using DBus which means that we could skip DBus usage for this purpose and \
> we would not need to tell people to install the service (DBus) that occasionally \
> has been flagged as mallware.
> You might argue that we should just compile support without installing the service, \
> but how do I know what features don't work without the service? If the frameworks \
> need special options to disable DBus I'm informed about what is disabled and can \
> choose if I need it or not. Without the option the feature is silently disabled. \
> This is the reason I want separate options for each framework that provides it and \
> not a global one in ECM.
> Almost all Qt users on Windows that I know of would not even dream of compiling \
> their own Qt and pre-compiled Qt comes with DBus support.
> René J.V. Bertin wrote:
> > can you explain this to me?
>
> An option here would allow using a single Qt install to build and bundle software \
> either with or without support for DBus.
> I wouldn't worry about the "pollution" aspect of redundant stuff here. There are \
> other things that are just as redundant and pollute a lot more (like "tons of" \
> translation files) and that are still installed because disk space is cheap \
> compared to the potential cost of being overly concerned about the overhead. It's \
> also cheap compared to the cost of building Qt from source.
> I'll repeat something too: if HB considers it appropriate to provide a pre-compiled \
> Qt version that doesn't include DBus support, than it's up to HB to assume any \
> consequences that might have on IPC abilities of dependent packages. For instance \
> by building with a specific cmake switch to disable DBus. MacPorts also provides \
> pre-compiled packages, only of the default port variants, but as much as possible \
> those default variants are conceived to cater to the needs of the largest number of \
> dependents. IOW, if most Qt5 dependents require DBus support, the Qt5 package that \
> most users would want to install should include DBus support.
> I agree that it seems acceptable to make DBus optional in the build system (that \
> could probably apply on Linux as well where QtDBus should always be available). \
> That requires only limited changes to CMake files. OTOH, littering the source code \
> with `#ifndef QT_NO_DBUS` lines is a change of a different order of magnitude IMHO, \
> one that should be hidden in a central class.
> > gtk-based apps require dbus to run on windows and osx
>
> No idea how many require it to *run*, but the real question is how many lack \
> features without DBus.
> KDE apps that don't require DBus presumably don't attempt to pull in QtDBus (or \
> could be patched not to).
> DBus is small, doesn't take up a lot of resources or hog the CPU, can be launched \
> as a system service via launchctl. Replacing it is going to require significant \
> effort across the board, most likely only to come up with something that is just a \
> reinvention of the same wheel. An effort better spent at making feel DBus more at \
> home on those other platforms, if you ask me.
> René J.V. Bertin wrote:
> > KDevelop has a solution for it without using DBus
>
> Have you tested if that actually works? I've tried their QtSingleApplication build \
> on OS X, but cannot find any connection to the FileOpen signal it emits when a file \
> open request is received through LaunchServices (and indeed, no file is actually \
> opened, the application is just raised as if it's about to open one).
> Remember that DBus isn't only used for asking an application to open a file, or to \
> check if an instance of the application is already running. The KDE Wallet uses \
> DBus to communicate with the kwallet daemon (and I'm more or less convinced now \
> that's a better solution than my attempt to provide the same feature set against an \
> OS X Keychain backend). And that's not even mentioning KDE PIM ...
> There's nothing wrong with limiting the use of DBus where feasible and justifiable \
> (in terms of code maintenance), but I don't really believe it's plausible (nor \
> justifiable in terms of effort) to change all of KDE so it uses DBus on \
> Linux/Unix+X11 and something else elsewhere. Reasons exposed in my previous posts. \
> And not in KF5, anyway. Maybe K?6 (KG6? :)) but in a way I hope I'll no longer be \
> around when that transition begins.
> Nick Shaforostoff wrote:
> > No idea how many require it to run, but the real question is how many lack \
> > features without DBus.
>
> examples are gimp and libreoffice, firefox, chrome and so on.
>
> i have implemented opening documents in an already running app instance in Lokalize \
> without using dbus on both osx and windows -- took me one day. you can see the code \
> at https://quickgit.kde.org/?p=lokalize.git&a=blob&h=80c18c8cdb5ef66b9e599b1e4e3ffd7afbbf2551&hb=c1f1e99f78bcabd004cf1fff073a79cd15695733&f=src%2Fmain.cpp
>
> i'll update the diff introducing a special cmake option this evening
> examples are gimp and libreoffice, firefox, chrome and so on
The only gtk-based application on OS X or MS Windows in that list is gimp.
Again, it's rather trivial to implement opening a document without DBus; on OS X that \
uses the same basic technique as opening a document in a not-yet-started application \
that isn't started from a terminal (LaunchServices doesn't pass documents to open via \
`argv`). But that's not all for which DBus is used.
Telling another application to open a file without using DBus is a different matter \
though.
- René J.V.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95405
-----------------------------------------------------------
On May 12, 2016, 7:16 a.m., Nick Shaforostoff wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> -----------------------------------------------------------
>
> (Updated May 12, 2016, 7:16 a.m.)
>
>
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, and \
> Martin Gräßlin.
>
> Repository: kauth
>
>
> Description
> -------
>
> this is the first patch to make kde frameworks build (and then work) without dbus.
>
> 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.
>
> Diffs
> -----
>
> CMakeLists.txt 48dc2d9
> autotests/BackendsManager.cpp 59675b3
> autotests/CMakeLists.txt b53d760
> autotests/HelperTest.cpp 8050a06
> src/CMakeLists.txt 1b6930d
> src/ConfigureChecks.cmake d46761a
>
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
>
>
> Testing
> -------
>
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
>
>
> Thanks,
>
> Nick Shaforostoff
>
>
--===============8835416500297821023==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
<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, 8:15 a.m. CEST, <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, 10:05 a.m. CEST, <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 ver y 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>
<p>On May 12th, 2016, 12:01 p.m. CEST, <b>Nick Shaforostoff</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;">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> \
</blockquote>
<p>On May 12th, 2016, 12:53 p.m. CEST, <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;">We have Kate as an \
example. At the moment the main thing we need DBus for on windows is opening \
documents in only one window when opening new documents through explorer. Without the \
DBus daemon it does not work. KDevelop has a solution for it without using DBus which \
means that we could skip DBus usage for this purpose and we would not need to tell \
people to install the service (DBus) that occasionally has been flagged as mallware.
You might argue that we should just compile support without installing the service, \
but how do I know what features don't work without the service? If the frameworks \
need special options to disable DBus I'm informed about what is disabled and can \
choose if I need it or not. Without the option the feature is silently disabled. This \
is the reason I want separate options for each framework that provides it and not a \
global one in ECM.
Almost all Qt users on Windows that I know of would not even dream of compiling their \
own Qt and pre-compiled Qt comes with DBus support.</pre> </blockquote>
<p>On May 12th, 2016, 1 p.m. CEST, <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;"><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;">can you explain this to me?</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">An option here would allow using a single Qt install \
to build and bundle software either with or without support for DBus. </p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">I wouldn't worry about the "pollution" aspect of redundant stuff here. \
There are other things that are just as redundant and pollute a lot more (like "tons \
of" translation files) and that are still installed because disk space is cheap \
compared to the potential cost of being overly concerned about the overhead. It's \
also cheap compared to the cost of building Qt from source.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I'll \
repeat something too: if HB considers it appropriate to provide a pre-compiled Qt \
version that doesn't include DBus support, than it's up to HB to assume any \
consequences that might have on IPC abilities of dependent packages. For instance by \
building with a specific cmake switch to disable DBus. MacPorts also provides \
pre-compiled packages, only of the default port variants, but as much as possible \
those default variants are conceived to cater to the needs of the largest number of \
dependents. IOW, if most Qt5 dependents require DBus support, the Qt5 package that \
most users would want to install should include DBus support.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I \
agree that it seems acceptable to make DBus optional in the build system (that could \
probably apply on Linux as well where QtDBus should always be available). That \
requires only limited changes to CMake files. OTOH, littering the source code with \
<code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: \
normal;margin: 0;line-height: inherit;">#ifndef QT_NO_DBUS</code> lines is a change \
of a different order of magnitude IMHO, one that should be hidden in a central \
class.</p> <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;">gtk-based apps require dbus to run on windows and osx</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">No idea how many require it to <em style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;">run</em>, but the real question is how many lack features without DBus.</p> \
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">KDE apps that don't require DBus presumably don't \
attempt to pull in QtDBus (or could be patched not to).</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">DBus \
is small, doesn't take up a lot of resources or hog the CPU, can be launched as a \
system service via launchctl. Replacing it is going to require significant effort \
across the board, most likely only to come up with something that is just a \
reinvention of the same wheel. An effort better spent at making feel DBus more at \
home on those other platforms, if you ask me.</p></pre> </blockquote>
<p>On May 12th, 2016, 1:11 p.m. CEST, <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;"><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;">KDevelop has a solution for it without using DBus</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Have you tested if that actually works? I've tried \
their QtSingleApplication build on OS X, but cannot find any connection to the \
FileOpen signal it emits when a file open request is received through LaunchServices \
(and indeed, no file is actually opened, the application is just raised as if it's \
about to open one).</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">Remember that DBus isn't only used for \
asking an application to open a file, or to check if an instance of the application \
is already running. The KDE Wallet uses DBus to communicate with the kwallet daemon \
(and I'm more or less convinced now that's a better solution than my attempt to \
provide the same feature set against an OS X Keychain backend). And that's not even \
mentioning KDE PIM ... </p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">There's nothing wrong with limiting the \
use of DBus where feasible and justifiable (in terms of code maintenance), but I \
don't really believe it's plausible (nor justifiable in terms of effort) to change \
all of KDE so it uses DBus on Linux/Unix+X11 and something else elsewhere. Reasons \
exposed in my previous posts. And not in KF5, anyway. Maybe K?6 (KG6? :)) but in a \
way I hope I'll no longer be around when that transition begins.</p></pre> \
</blockquote>
<p>On May 12th, 2016, 2:25 p.m. CEST, <b>Nick Shaforostoff</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;">No idea how many require it to run, but the real question is how many lack \
features without DBus.</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">examples are gimp and libreoffice, firefox, chrome and \
so on.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">i have implemented opening documents in an already \
running app instance in Lokalize without using dbus on both osx and windows -- took \
me one day. you can see the code at \
https://quickgit.kde.org/?p=lokalize.git&a=blob&h=80c18c8cdb5ef66b9e599b1e4e3f \
fd7afbbf2551&hb=c1f1e99f78bcabd004cf1fff073a79cd15695733&f=src%2Fmain.cpp</p> \
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">i'll update the diff introducing a special cmake \
option this evening</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;"><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;">examples are gimp and libreoffice, firefox, chrome and so on</p> \
</blockquote> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">The only gtk-based application on OS X or MS Windows \
in that list is gimp.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">Again, it's rather trivial to implement \
opening a document without DBus; on OS X that uses the same basic technique as \
opening a document in a not-yet-started application that isn't started from a \
terminal (LaunchServices doesn't pass documents to open via <code \
style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: \
0;line-height: inherit;">argv</code>). But that's not all for which DBus is used.</p> \
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Telling another application to open a file without \
using DBus is a different matter though.</p></pre> <br />
<p>- René J.V.</p>
<br />
<p>On May 12th, 2016, 7:16 a.m. CEST, 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, 7: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>
--===============8835416500297821023==--
[Attachment #3 (text/plain)]
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic