> 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.
> 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. - 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
