[KDE/Mac] Review Request 127896: make dbus optional on osx: kauth

Thu May 12 10:53:45 UTC 2016

> On May 12, 2016, 6: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 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.
>     
>     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?

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.

- Kåre

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95405
-----------------------------------------------------------

On May 12, 2016, 5: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, 5: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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20160512/63996525/attachment.html>