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