> 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.
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 ex pect 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). - 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
