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